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. 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. 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. 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' bar, and an artifact is only allowed downstream once it clears that bar. The diagram below shows the two tracks descending from a single idea, each passing through its review gates on the way to build-ready.

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. 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.