Product engineering
The whole build, owned by one party. Data model, backend, interface, infrastructure and deploy, delivered as a product your own team can pick up and keep running.
| Engagement | Project or ongoing |
|---|---|
| Built for | Companies without an engineering team |
| Price | Quoted on scope |
One accountable party
The same people design the schema, write the API, build the interface and run the deploy. Nothing falls into a gap between vendors.
An interface with care taken
Fast, keyboard-navigable and accessible, whether we are building to your designer's work or shaping it ourselves.
Infrastructure you own
Your cloud account, your domain, infrastructure as code, and a pipeline that makes deploying routine.
A handover that works
Conventional code, tests, and written decisions, so onboarding an engineer is a week of reading rather than an excavation.
One party owns the whole thing
The usual arrangement splits a product across a design agency, a backend contractor and a frontend contractor, and puts a project manager on top to keep them talking. Most of the budget goes into the seams.
We take the whole build instead. The same people who design the data model write the API and build the screens on top of it, which is why the schema tends to fit what the interface needs.
What that includes
- The data model, designed for the questions the product will ask
- Services and APIs, tested, with sensible error handling rather than optimistic paths only
- The interface, fast and accessible down to keyboard and screen reader
- Infrastructure and deploys, as code, in your accounts
- The handover, documented well enough that we could disappear
Built to outlive its first version
Products live far longer than their first build, and most of the cost arrives later. So the code is conventional rather than clever, the tests exist, and the decisions are written down with their reasoning.
When you hire your own engineers, they inherit something legible. That is the point.
Working alongside an existing team
If you already have engineers, we can take one part of the product and stay out of the rest, or set up the platform and practices and hand them back. We will not quietly become a dependency you cannot remove.
What do you build with?
TypeScript end to end, React on the front, Node and edge runtimes on the back, Postgres underneath. Go or Rust where they earn their place. Native mobile when the product genuinely needs it.
Can you work with our designer?
Yes, and we would prefer to. We can build to finished designs, or take a rough direction and make the interface feel considered ourselves.
What if we hire an engineering team later?
Good. That is the intended ending. The code is conventional and documented precisely so a new team can take it over without a rewrite, and we will help onboard them.
Do you do mobile?
Web first, native when the product requires it. We have shipped a native app alongside an app-store launch, including the payment and game-server integrations behind it.
How is this priced?
Build work is scoped and quoted per phase, so you know what a phase costs before it starts. If what you actually need is consultancy rather than delivery, that is billed hourly instead, and we will say so rather than force a scope around it.
Tell us the one thing it has to do.
If it's sharp enough to prove in a week, we'll say so and give you a date. If it isn't, we'll tell you that too, along with what we'd build first instead.