Specification-Led Delivery™
"AI-first" is doing a lot of work in most studio pitches. This is the version with the mechanism written down, including what it does not fix.
The unit of work is a written specification, not a person-hour. You approve what should exist; agents produce it in parallel; review lands where being wrong is expensive.
One person specifies. A fleet types.
A traditional team splits work by person: each engineer owns a slice and the coordination between them is the overhead. We split it by specification instead. One person defines what should exist and reviews what comes back; coding agents produce it in parallel, across the whole codebase at once.
The effect is that typing stops being the constraint. What remains is deciding precisely what to build, which is where the risk always was. So the schedule front-loads thinking and the rest is execution.
- A vague idea. Agents build the wrong thing faster.
- Slow decisions on your side. The format runs on same-day answers.
- Third-party systems you do not control.
- App-store review, which takes as long as it takes.
- Problems that need research rather than engineering.
A studio bills you for hours. A model bills you later.
There are three ways to get software built right now. Two of them are cheaper to explain and worse to live with.
Scroll the table →
| A traditional studio | AI tooling on its own | Specification-Led Delivery | |
|---|---|---|---|
| Unit of work | A person-hour | A prompt | A written specification you approved |
| What sets the pace | Headcount, and the coordination between them | Nothing, until it is wrong | How fast you can decide |
| Review | Peer review, where the schedule allows it | Whatever you happen to catch yourself | Aimed at the data model, the interfaces, and anything touching money, auth or data loss |
| Cost | Scales with hours | Cheap now, expensive later | Fixed against a written scope, or hourly for advisory |
| Accountability | A team, and it diffuses | Nobody | One engineer, named before you sign |
| What you hold at the end | A codebase and an invoice | Code nobody has read | Your repo, your cloud account, documented |
The speed row is the one everybody leads with, and it is the least interesting: generated code is fast wherever it comes from. The rows that decide whether you regret this in a year are the last two.
Scope
Day 1
We cut the work down to the smallest thing that proves the idea, and write down what "done" means in terms you can check. This is the day that decides whether everything after it works, so it gets a real conversation rather than a form.
Build
The bulk of the engagement
Coding agents work in parallel across the codebase while we review continuously, aimed at the design, the data model and the paths where being wrong is expensive. You get a working deploy at the end of each day, so there is never a week where you cannot see progress.
Harden
Before launch
Tests, error handling, the paths people take when things go wrong, and the boring security defaults around secrets, access and backups. This is where fast delivery either holds up or does not.
Handover
The end
Documentation, a walkthrough, and the decisions written down with their reasoning. The engagement has failed if you cannot operate what we built without us.
The obvious objection
If a machine writes the code, who is accountable when it is wrong? The same person who would be accountable otherwise. An agent's output is a draft, and it is read by someone who has run production systems for fifteen years and knows what fails at three in the morning. Nobody reads every generated line, here or anywhere claiming otherwise at this volume. Review goes where being wrong is expensive: the data model, the interfaces between parts, and anything touching money, authentication or data loss. The rest is held by types, tests and a narrow set of conventions. That is how review works on any team big enough that one person cannot read everything.
What changes is the ratio. Far more time goes into reading code, designing schemas and thinking about failure modes, and far less into typing boilerplate. That is a better use of senior attention than the traditional arrangement, where the senior engineer spends half the week writing CRUD endpoints.
Why the code stays conventional
Speed is often used to justify shortcuts, but the argument does not apply here. Tests, types and documentation are cheap to produce when generation is cheap, so there is no trade to make. The instruction is to write the boring, obvious version of everything, because the boring version is what a stranger can maintain in two years.
What you can verify
Ask to see the repository during the build rather than at the end. Ask what the test coverage is. Ask us to walk you through a decision and explain the alternative we rejected. A studio that cannot answer those in detail is not reviewing its own output.
Six of these are in the contract, not on the website.
Anyone can write reassuring things on a page. These are the ones we sign, and you can hold us to them.
You own the code from the first commit.
The repository is yours, not licensed to you. There is no vendor copy, no shared component library you have to keep paying for, and nothing you would have to negotiate to walk away with.
It runs in your accounts.
Cloud, domain and third-party services are provisioned under your billing from the start, not migrated to you at the end. We hold access while we work and lose it when we stop.
The price is agreed before code.
A build with a definable outcome is quoted as a fixed price against a written scope. Advisory work is hourly, because there is no deliverable to fix and pricing it as one would be a fiction.
An overrun is our cost.
On a fixed scope, if we misjudged the estimate we finish it anyway at the agreed price. If you add to the scope we price the addition before starting it, so nothing arrives as a surprise on an invoice.
One named engineer is accountable.
You meet the person responsible for the work before you sign, and they stay responsible for it. Not a pool, not a rotating account manager, and not an agent nobody is answering for.
Handover is documented, always.
The engagement has failed if you cannot operate what we built without us. That means a walkthrough, a README that works on a clean machine, and the decisions written down with the reasoning behind them.
If a clause here does not appear in the agreement you are sent, that is our mistake and we will fix it before you sign.
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.