Product engineering
You need a product built and have no engineering team to build it. We build all of it, from data model to deploy, as one accountable party, and hand over code your future hires can pick up without a rewrite.
| 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 build to your designer's work or shape 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.
Why hire one team instead of three vendors?
Because then one party owns the data model, the API, the interface and the deploy, and nothing falls into the gaps between them. The usual split (a design agency, a backend contractor, a frontend contractor, and a project manager to keep them talking) spends most of the budget on the seams.
We take the whole build. The people who design the data model also write the API and build the screens on top of it, so the schema fits what the interface needs.
What does a full build include?
Everything between the idea and a product your own team can keep running.
- The data model, designed for the questions the product will ask
- Services and APIs, tested, with error handling for the unhappy paths
- 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
Your first engineering hire inherits something legible
Most of a product's cost arrives after its first version. So the code is conventional rather than clever, the tests exist, and decisions are written down with their reasoning. When you hire engineers, they can start working instead of excavating.
If you already have engineers
We take one part of the product and stay out of the rest, or set up the platform and practices and hand them back. We do not 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 needs it.
We already have a designer. Does that clash?
No, we prefer it. We build to finished designs, or take a rough direction and shape the interface ourselves.
What if we hire an engineering team later?
That is the intended ending. The code is conventional and documented so a new team can take it over without a rewrite, and we 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.
Why quote per phase instead of one number?
So you know what each phase costs before it starts. Advice without delivery is billed hourly as consultancy instead.
Tell us what the product has to do.
A few lines on the product, the users and the deadline. Within one business day we reply with questions or a phased scope, each phase priced before it starts.