The Greenfield Workflow

Greenfield means a blank slate: a fresh idea with no existing code to wrestle with. That freedom is a trap if you start typing immediately. The discipline that makes greenfield work go smoothly is to treat one idea as the head of two rivers that flow in parallel — one answering what should be built, the other answering how it should be built — and to put a real review gate at each bend before the water is allowed downstream.

The mistake beginners make is collapsing what and how into a single rushed conversation. Keeping them separate is what keeps the work clean. The functional track is about behavior and business value: what the system should do, for whom, and how you'll know it's right. The technical track is about implementation: which stack, which patterns, which services. Both start from the same idea, both run at the same time, and both have to reach a build-ready state before anyone writes feature code. They are independent enough that a problem on one track doesn't silently corrupt the other.

On the functional side, the idea is first turned into a detailed spec. The single most important habit here is a don't-guess-silently loop: whenever the idea is ambiguous, you surface the open question rather than quietly inventing an answer. Number the questions so the business can answer them by reference, fold the answers back into the spec file, and go round again, because answers often raise new questions. The loop ends when the list is empty or every remaining item is explicitly marked as deferred. An unspoken assumption is the cheapest thing to fix now and the most expensive thing to fix after it's built.

Once the spec holds together, it goes to a product/business review — the people who own the value confirm it's the right thing. Only then does the spec become user stories, each carrying Given/When/Then acceptance criteria so 'done' is testable rather than a matter of opinion. A useful trick at this stage: ask for a list of any part of the spec that can't be turned into a clear story. Whatever lands on that list is a spot where the spec is still ambiguous. The stories get a final approval, and the functional track is build-ready.

The technical track does not begin by inventing a stack from scratch. It begins from gold standards — the organization's agreed defaults for languages, frameworks, and patterns. You only reach for an ADR (Architecture Decision Record) when you genuinely need to deviate from those defaults: a new library, a new external service, or a technical approach the standards don't cover. Whether you stay on the paved path or deviate, an architect approves the direction before it's drawn up into architecture docs, which then get a second architect sign-off. With that, the technical track is build-ready too. (The standards-and-ADR machinery has its own lesson — see gold standards & ADRs.)

The thread tying both tracks together is the golden rule of the gate: don't just produce an artifact — produce one good enough to pass review. A spec nobody could approve, or an architecture doc the architect would bounce, hasn't moved the work forward; it's just created the illusion of progress. Each gate has an explicit 'approvable' checklist, and an artifact is only allowed downstream once it clears that bar. Run the checklist yourself before you ask for a review, so you don't spend a reviewer's time on something that was never going to pass. And nobody approves their own work: specs and stories go to the product owner, ADRs and architecture docs to the architect.

Step through one feature, loyalty points, as it travels down both paths. Each gate is a barrier that opens only when the checklist beneath it is fully ticked. When a story reaches its gate with a vague criterion, predict what happens before you look. Afterwards, switch the reviewer to Rubber-stamps to see what the gate was protecting you from.

A chat is a conversation; a spec is a contract. When the agreed behavior lives only in a thread of messages, it gets contradicted, forgotten, and lost when the window scrolls. Write the approved spec and stories into a file that ships with the project, and paste or point to that file at the start of each round rather than relying on a long chat history. That file is what later work will trust. Greenfield done well is just spec-driven development with the gates made explicit; the next disciplines to study are the spec-driven mindset that feeds the tracks and the gold standards & ADRs that anchor the technical one.