From PRD to Production: How We Start a New Build

The hard part of starting a project has never been writing the code. It is getting everyone — including, now, the agents doing much of the typing — to agree on what is being built, why it is built that way, and what “done” means.

AI made the typing dramatically faster. It did nothing for the agreement problem. If anything it made it worse, because an agent with no shared context will produce something confident, plausible, and subtly not what you asked for, at speed.

Here is how we take a new build from PRD to first shipped slice, and which parts we deliberately keep slow.

The Pipeline

Every project follows the same sequence, and each artifact reads the one before it:

The PRD is owned by us and the client. It is also, counterintuitively, where we use AI most heavily — not to write it, but to interrogate it. Everything downstream is generated from it, reviewed, corrected, and only then used as input to the next step.

The architecture document records what was chosen and why — stack picks with alternatives considered, data model, multi-tenancy posture, API style, non-functional requirements traced back to specific PRD lines. The design system normalises tokens and component specs. The dev handoff turns both into something a developer or an agent can start executing immediately: endpoint signatures, component-to-screen mapping, acceptance criteria, an ordered build sequence.

The gates in that last step are two automated reviews that every slice has to clear before it can merge: one for security, benchmarked against OWASP Top 10:2025 and the API, GenAI, and agentic checklists where they apply, and one for performance. Each finding carries a severity and a separate confidence rating, and a critical finding blocks the merge outright. They have a post of their own — worth reading if you want the detail on how they work and why the two ratings have to stay separate.

None of this is novel. What matters is the discipline around it.

One Document at a Time, On Purpose

Our tooling could generate all five artifacts in a single run. It is explicitly built not to.

The reason is that each document is the input to the next. An unreviewed assumption in the architecture does not stay in the architecture — it becomes a schema, then an endpoint contract, then a screen, then a shipped feature. By the time anyone notices, the wrong decision is load-bearing across four documents and a codebase.

So the pipeline stops after every artifact and waits. Even when someone says “just bootstrap the whole thing,” it produces one document, summarises what it did, names the next step, and stops.

This is the same principle we apply when reviewing AI-generated code: speed is only valuable if there are checkpoints where a human can still cheaply change direction. Generating five documents in ninety seconds feels productive. Discovering on day nine that the second one was wrong is not.

Interrogation Before, Inference Never After

There is an asymmetry in how we use AI across this pipeline, and getting it backwards is the most common mistake I see.

While the PRD is being written, we want the model as involved as possible. It is a long back-and-forth: challenging assumptions, pointing out where two requirements contradict each other, asking what happens to the edge case nobody thought about, pushing on what “done” means for a feature described in one line. Half the value is the questions we would not have thought to ask. The other half is discovering, early and cheaply, which parts of the idea the client has not actually decided yet.

That interaction is worth a great deal, because the cost of a question scales with when you ask it. A gap surfaced during PRD drafting costs a conversation. The same gap surfaced during implementation costs a sprint, and usually a rework of something already built on the wrong assumption.

The output of that process is still human-owned. The model interrogates; it does not decide. Scope, priorities, and trade-offs come from the people accountable for the product.

Then the mode flips completely.

The PRD Is the Only Source of Truth

Once the PRD is agreed, the single most important rule in the rest of the process: never invent product requirements.

A language model asked to write an architecture document from an incomplete PRD will produce a complete architecture document. It will fill the gaps. The output will be coherent, well-structured, and will contain decisions nobody made — a retention policy, a tenancy model, an auth flow — presented in exactly the same confident tone as the parts that came from the actual specification.

That is the failure mode worth designing against, because it is invisible. Nothing looks wrong.

So anything the PRD leaves ambiguous goes into a Risks and open questions section rather than being resolved. Unanswered questions stay visibly unanswered. It is a shorter document and a more honest one, and the gaps are exactly the list you want to walk into a client conversation holding.

Defaults That Announce Themselves

We have a house stack — Angular client, .NET minimal API, Postgres with EF Core migrations, in a monorepo. It is the default because it is what we are fastest and safest in, not because it is right for every product.

Several things are deliberately not defaulted:

• Database provider — Postgres, yes, but managed by whom is project-dependent
• UI component framework — chosen per project, never silently assumed
• Font — comes from the design system, not the scaffold
• Text direction — determined from the PRD; never assumed to be either LTR or RTL

That last one matters more than it sounds. A scaffold that quietly assumes left-to-right will produce layouts that need unpicking later if the product ships in Hebrew or Arabic. Guessing is worse than asking, so it asks. And regardless of direction, layouts use CSS logical properties so the decision stays cheap to change.

Every default that is applied is written into the generated conventions file marked as overridable. A default you cannot see is not a default, it is a constraint.

Decisions Get a Paper Trail

Significant either/or choices surfaced during architecture become architecture decision records — context, decision, alternatives considered, consequences. Numbered, append-only, never deleted; superseded ones stay and link forward.

This used to be a nice-to-have. With agents doing implementation work it has become load-bearing. When an agent picks up a task six weeks later, the ADR is the difference between it understanding a constraint and it cheerfully refactoring around one. “Why is this queued instead of synchronous?” has an answer sitting in the repo, versioned alongside the code.

The same logic drives per-stack convention files. An agent working in the client folder loads Angular conventions. One working in the API folder loads .NET conventions. Neither loads both, because irrelevant context is not free — it dilutes attention and invites the model to apply the wrong idiom.

Living State, Then Code

Three files carry state through the build: a changelog, a status snapshot, and an open task list. They exist so any session — human or agent — can resume without reconstructing where things stand from commit archaeology.

Then the building starts — and unlike everything above it, the build is not a pipeline. It is a loop.

The Build Loop

The document pipeline runs once. The build cycle runs on every slice, and it is genuinely iterative rather than a checklist you walk down once.

A slice starts as code plus its tests. It gets reviewed and exercised — automated runs, and a human actually reading the diff, which matters more when an agent wrote it. Then both gates run: security and performance, each producing findings rated for severity and confidence.

What happens next is the part worth being precise about. A critical finding blocks the merge outright. Lower-severity findings are either fixed or explicitly deferred with a note. Anything the reviewer marked as needing verification has to be checked rather than waved through, because its real severity is still unknown. Any of those outcomes sends the slice back to the top of the loop.

That return trip is normal, not a failure. A slice going round two or three times is an ordinary week. The gates are not a formality you clear on the way out — they are the mechanism that decides whether the slice is finished, and the answer is frequently “not yet.”

Only when everything passes does the work reach a pull request and get merged. Then the ceremony files get updated, and the next slice starts the loop again.

Two things make this work rather than becoming theatre. The gates run per slice, not just at PR time — catching a problem while the context is still in someone’s head is far cheaper than catching it across a large merged diff. And the definition of done lives in the handoff document, so “done” means the same thing in week nine as it did in week one, regardless of who or what is doing the building.

What This Actually Buys

Not speed, exactly. The generation is fast; the reviewing between steps is not, and it is not meant to be.

What it buys is that by the time code is being written, the decisions have been made explicitly, recorded where they can be found, and reviewed by someone who can tell a good assumption from a plausible one. The agent has real context instead of inference. The client has seen the open questions rather than discovering them as surprises in week three.

The scaffold is the cheap part. Agreement is the expensive part, and it is the part worth spending time on.

Starting something new and want the setup done properly? Talk to the quickdev team.