Product and web engineering
Client portals, internal tools, dashboards, and the sites that carry your firm's argument — designed and shipped by one team.
A website layout takes shape, becomes a finished design, and adapts to a phone screen. An illustrative concept showing responsive web design and engineering.
What it is
Some problems are not agent-shaped. A client cannot see where their matter stands, so somebody answers that question by email all week. Three teams keep the same spreadsheet in three states. The site that carries your firm's argument was built for the firm you were two years ago. These need software, built properly, with an owner afterwards.
We design and ship client portals, internal tools, dashboards, and public sites with the people who will spend their days in them, in one team from scope through launch. When an agent or a knowledge system needs a surface a person can work in — a queue, an approval screen, a status page a client can open — this is where that surface gets built.
How it runs
Step 01. Decide
The first question is whether to build at all. Plenty of problems are better answered by fixing a process or configuring a tool you already pay for. When building wins, we write the scope down with its exclusions, because the exclusion nobody stated becomes the argument in week six.
- A build, buy, or stabilize recommendation
- User and permission map
- Scope with the exclusions written down
- A data model decision
Step 02. Build
We ship in slices your team can use rather than one release at the end. Accessibility, performance, and search foundations get checked as the work happens instead of audited afterwards. The launch checklist is written well before launch week and signed by the person who owns the result.
- A working prototype in staging
- Accessibility and performance checks
- A staged release plan
- A signed launch checklist
Step 03. Operate
The work does not end at deploy. Ownership moves to a named person on your side, who can change the content without opening a ticket and knows who to call when something breaks. Alerts go somewhere a person actually reads. The documentation is written for whoever inherits it.
- Handover documentation
- A named owner
- Monitoring and error alerts routed to a person
- A support and change path
Who this is for
Founders and CEOs
The site describes the firm you were two years ago, and every small change needs an agency and a waiting list. The public surface matches what you now sell, and your team can edit it.
Operations
Clients email to ask where things stand, and answering them is somebody's whole morning. A portal shows status as work moves, so the update happens without anyone writing it.
Marketing
Half the week goes to moving numbers between tools so a report can exist on Monday. The reporting surface gets built once, and the week goes back to the campaigns.
Example engagements
Two distinct brands, one connected platform.
One website became two distinct brand sites, with a cost calculator and weekly emails that bring new inquiries together for the team.
Read the case studyA shared view of shipping delays and customer follow-up.
Store orders and parcel-tracking updates brought together for delivery reporting, delay review and customer email drafts requested by staff.
Read the case studyQuestions
Should we build a custom tool or buy software?
Buy when a well-established product covers most of what you need and you can live with its opinions. Build when the process is genuinely particular to your firm, when the value is in connecting systems that do not talk, or when the workarounds have quietly become the process. We give you that recommendation in writing before anyone opens an editor.
Do you build on our stack or bring your own?
Yours where it is sound. We work with mainstream, maintainable technology and integrate with the CRMs, document systems, and databases your firm already runs. Where we do choose, we choose for the developer you might hire in two years, not for what is interesting this quarter. Nothing is built on a platform your team cannot staff.
Who owns the code and the accounts?
You do. Repositories, hosting, domains, and third-party accounts are in your firm's name, and the handover includes the access to prove it. Nothing we build depends on an account only we can reach. If you decide to take the work elsewhere, everything needed to continue it goes with you.
Do you handle design as well as engineering?
Yes. Interface design, content structure, and engineering happen in the same team, which is why the prototype looks like the product rather than like a wireframe. For public sites that includes the copy structure and search foundations. We do not hand a design over a wall and hope it survives the build.
What happens after launch?
Ownership sits with a named person on your side, who gets documentation written for them and a defined route for changes. Monitoring reports to a human. Where you want us to stay involved, that continues as defined work with a scope, not an open retainer. Where you want to run it yourselves, the handover is built for that from the start.
The other capabilities
AI strategy and opportunity design
Interviews with the people doing the work, an opportunity map ranked by effort and value, and one funded decision — tested with a prototype before the budget commits.
See the serviceAgentic systems and automation
Agents that carry the routine steps of a workflow and stop for a named person at every judgment call, with the limits written down before anything gets built.
See the serviceKnowledge and document systems
Retrieval built on the documents your firm approved, with the source on every answer, an owner on every collection, and a schedule that keeps the library current.
See the serviceStart withthe businessproblem.
Thirty minutes. You describe what's slow, manual, or opaque today. We tell you honestly whether we're the right firm to fix it.
30 minutes