Spec-to-production builds
On time, on budget, production-ready. No black box.
A senior architect directs the Greenfield Production System through discovery, architecture, specification, implementation, and quality review. You keep the journey specs, the ADRs, the tests, and the gate transcripts.
The default paths
Three ways platform builds usually go
Founders with a deadline and a data asset get handed the same three options. Each one trades away something the others don't.
The offshore shop
The quote looks right and the first demo arrives on time. Then the spec drifts, and your senior engineers spend their evenings reviewing pull requests across time zones. The real cost lands on your own payroll, in review hours that never appear on an invoice.
The onshore agency
Senior people run the pitch; a different bench runs the build. Hours are billed against a scope that stays open, so nothing in the contract rewards finishing. Months in, you own a slide deck and a half-integrated system.
The internal team
The right call when you have the time, since the people who build the platform stay to run it. Recruiting them takes months before the first commit, though, and the platform team you hire for the build is payroll you carry long after launch. A competitive window rarely waits that long.
Our answer is a production line rather than a staffing model: agents do the volume, an architect makes the calls, and 31 gates (view the artifact) decide what moves forward. The rest of this page walks through it.
Method
Five phases, one production line
Agents do the volume; a senior architect makes the calls and owns the engagement. Between stations stand 31 gates (view the artifact) . The split below is honest about which checks are deterministic and which are judged.
- 01
Discovery
- Agents
- Map the domain: actors, capabilities, events, service boundaries. Any existing code is analyzed in parallel.
- Architect
- Runs the elicitation with your domain expert and resolves the ambiguities the agents can’t infer from source.
- You
- 1–3 hours of a domain expert’s time, asynchronous.
- 02
Architecture
- Agents
- Draft the context map, service interaction diagrams, and typed contracts between every service.
- Architect
- Makes the trade-off calls. Every significant decision lands in an ADR with its rationale and the alternatives considered.
- You
- Plan a full day for review and iteration. Implementation doesn’t start until you approve.
- 03
Specification
- Agents
- Project the journey specs, API specs (one per endpoint), and view specs from the approved architecture.
- Architect
- Reviews where judgment is irreducible, then freezes the spec set with you.
- You
- Approve the specs. They become the fixed scope; changes after approval go through explicit change control.
- 04
Implementation
- Agents
- Implement every handler against the spec templates. An AST pattern validator checks each one before the quality gates run; a wrong signature or base class fails on the spot.
- Architect
- Reviews escalations from failed gates rather than the code volume.
- You
- Progress visibility throughout. Nothing blocks on you.
- 05
Quality review
- Agents
- Run the gate loop: fix, rerun, repeat. When the line claims every gate passes, the system reruns them independently before anything ships.
- Architect
- Final review, then the system walkthrough with your team.
- You
- 2–4 hours for the walkthrough and handoff.
The 31 gates, in two kinds
Deterministic
Compilation, coverage thresholds, contract validation, authorization checks. Pass or fail, with no judgment involved and nothing to argue with.
LLM-judged
Spec fidelity and the quality dimensions a script can't score, each graded against a written rubric. A score under 90 fails the gate.
Every run is logged. Read an annotated gate transcript, failures included.
One station you won't find: Gherkin generation. The consuming team rejected the generated Cucumber features, so we retired the format in favor of the behavior catalog. That story is an essay.
What you keep
The specs are the deliverable
A new engineer can read the specs and understand the system without a walkthrough. These documents are the deliverable; the code is their consequence.
- Journey specs
- Every user-visible flow written as checkable behavior, from sign-in to the edge cases.
- API specs
- One per endpoint: inputs, outputs, authorization, and failure modes.
- View specs
- What each screen shows, and under which permissions.
- ADRs
- Every significant architectural decision with its rationale and the alternatives we considered and rejected. The trade-offs survive the meeting they were made in.
- Domain context map
- The bounded contexts and the events that cross between them.
The CIO press calls this approach specification-first and prizes traceability over velocity for mission-critical work. We'd put it more concretely: a gate validates every handler against its spec, the tests derive from the spec scenarios, and the transcript records that both checks ran.
Case study
OTR Select: spec to production in six weeks
A production SaaS platform built around the client's data asset. The delivery schedule is published week by week below; we'd rather show the calendar than claim a multiple against somebody else's baseline.
| Week | Phase | What shipped |
|---|---|---|
| 1 | Discovery | Domain map: actors, capabilities, events, service boundaries. |
| 2 | Architecture | Context map, typed service contracts, ADRs. Blueprint reviewed and approved. |
| 3 | Specification | Journey, API, and view specs approved; scope fixed. |
| 4 | Implementation | Backend services through the gate pipeline. |
| 5 | Implementation | Frontend and integrations through the same gates. |
| 6 | Quality review | Full-suite runs, staging verification, production cutover. |
The system shipped with 536 test files at a 20:1 test-to-endpoint ratio (view the artifact) , and the client kept the full inventory: 19 journey specs, 26 API specs, 7 view specs (view the artifact) , plus the ADRs behind every structural decision.
Provenance
Built on Factory v1: every line AI-written, with an architect reviewing at stations that are now automated gates.
Read the full chaptered case study, including what the verification factory later found in this same estate.
After launch
Operated by the people who built it
Code built from specs, with coverage at every layer, fails less. That's why we can put response times in writing.
- Incident response
- Production incidents go to a named engineer, around the clock, with the acknowledgment window written into the agreement.
- Defect turnaround
- Confirmed defects are scoped against a committed window, and the fix ships through the same gate pipeline as the original build.
- Monthly reporting
- A written report each month: uptime, incidents, changes shipped, and the test runs that verified them.
Managed operation is optional, and so is staying: you own the source, the specs, and the deployment configuration either way. Teams that want the test suite re-generated and re-run on every release can add per-release verification as a subscription.
Fit
Whether this is for you
- You’re building a production platform, often around a data asset, and your window is measured in months rather than years.
- You can give us a domain expert for a few hours in week one, and a decision-maker for a working day of architecture and spec review.
- You want fixed scope agreed at spec approval, with changes through explicit change control: an outcome-based contract, not billed hours.
- You intend to hire engineers who will inherit the system. The specs are written for them.
- The work needs to survive technical diligence, so every claim about the build should come with an artifact.
If what you need is staff augmentation inside your own sprint process, we're the wrong shape; the production line works as a whole or not at all.