Build
Digital product delivery
Getting a product designed, built, shipped and operable by the people who will own it after we have gone.
We build software. Not as a body shop and not as a permanent outsourced engineering department, but as a delivery team that takes a product from a description to something running in production with real users on it.
The distinguishing constraint is handover. Every technical decision is taken with the question of who maintains this in eighteen months in view, which rules out a good deal of clever architecture and most of the frameworks that make a demo fast and an inheritance painful.
What you get
Named artefacts, not a slide pack. Each one is a thing your team can open, run, or hand to an auditor.
| Artefact | What it contains |
|---|---|
| Shaped scope | What is being built and, more usefully, what is explicitly not, with the cut line written down before work starts. |
| Working software in production | Deployed, on a domain, with TLS, backups and a way to see what it is doing. Not a staging environment. |
| Deployment path | A documented, repeatable route from a commit to production that someone else can run. |
| Operational baseline | Logging, alerting, backup and restore. Restore tested, not assumed. |
| Architecture decision records | What we chose, what we rejected, and the condition that would make us revisit it. |
| Handover documentation | Written against the questions your team actually asked during the last two weeks, not a template. |
How it runs
01 · 1–2 weeks
Frame
What the product must do, who for, and the constraints that are real. Ends with a costed scope and the parts we recommend cutting.
02 · 2–4 weeks
Prove
The riskiest part built first. If something is going to sink the project, we would rather find it in week three.
03 · 8–16 weeks
Build
Iterative delivery into a real environment, with the operational work done alongside the features rather than after them.
04 · 2–4 weeks
Hand over
Your team deploys, breaks and restores it while we watch. Documentation is finished last because that is when we know what it needs to say.
What we use
Chosen per engagement against your constraints. We have no reseller relationships and no incentive to recommend one of these over another.
Application
Data
Infrastructure
Commerce and integration
What we do not do
Knowing where our usefulness stops saves everyone a procurement cycle.
- We do not take on fixed-price fixed-scope contracts for work that has not been framed. We will fix a price once there is something specific enough to price honestly, which is normally after Frame.
- We do not build on a stack nobody in your organisation can hire for. Novelty in the platform layer is a cost your successor pays.
- We do not hold your production credentials hostage. Infrastructure is provisioned in your accounts, in your name, from the first week.
- We do not ship without backups and a tested restore. This is not negotiable and it is not an optional line item.
Questions we are asked
What does it cost?
Frame is a fixed fee because its scope is known. Everything after it is priced once we have framed it, because a number produced before that is either padded or wrong. What we can say is that the largest cost driver is almost never the feature list. It is unclear ownership of decisions on the client side, which turns a two-day question into a three-week one.
Can you take over a build somebody else started?
Sometimes. We start with a short assessment: read the code, run it, try to deploy it, talk to whoever wrote it if they are still reachable. The output is a straight answer on continue or restart with the reasoning shown. We have recommended restart and we have recommended continue, and the assessment costs a great deal less than getting that decision wrong.
Do you use AI to write the code?
Yes, extensively, and we are specific about how. AI does the work and engineers control the design and architecture. The failure mode with AI-assisted building is not bad code, it is a codebase nobody on the team can reason about because no human ever held the shape of it. Guarding against that is a review discipline, not a tooling choice. Our sister practice QAI Labs exists largely to do this properly.
What happens if we want you to keep running it?
That is a separate arrangement, agreed explicitly rather than by default. The build engagement is designed to end with your team capable of running the thing, and any ongoing involvement should be a decision you make from that position rather than one you back into.
Start with what is in the way.
Most of this work is shaped by the obstacle rather than the ambition. A deal that keeps stalling at the same stage, a process nobody owns, a product that will not sell, a decision that has been open for months. Tell us yours and we will say honestly whether we are the right people for it.