This tension runs underneath most of the practices in this series. Making it explicit helps you pick the right mode at each stage of the work.
Top-down starts from the highest-level model, requirements, domain, architecture, and works toward implementation. It asks: what are we building? What does success look like? What structure should this system have?
Bottom-up starts from concrete, working pieces and builds upward. It asks: what actually works? What do the real constraints look like? What can I demonstrate right now?
Where top-down fails
Design without bottom-up validation produces architecture that looks correct on paper and breaks against real constraints. The longer you stay in the design space before touching implementation, the more assumptions pile up, and every one is a potential mismatch with reality. The classic failure: a team spends six weeks designing an elegant layered architecture, starts implementing, and discovers the bottom layer’s performance requirements make the clean abstractions above it untenable. Top-down also drifts toward over-engineering, because when you’re working purely with abstractions, adding one more layer costs nothing you can see.
Where bottom-up fails
Bottom-up without top-down framing produces components that work locally and don’t cohere globally. Build pieces without a shared model of the domain and they develop incompatible assumptions about it. Pure bottom-up is also prone to solving the wrong problem efficiently: without “what does success look like,” it’s easy to build something precise that answers the wrong requirement.
The oscillation model
The most effective approach oscillates between the two.
1. Top-down framing
What are we building? What does success look like?
(Plain English requirements, completion test)
2. Bottom-up spike
What's the hardest or most uncertain part?
Build that first to validate feasibility.
(Plan B method, prototype)
3. Top-down design
Now that real constraints are known, design the architecture.
(Data model, state machines, API contract)
4. Bottom-up delivery
Build in vertical slices — complete, working increments.
Each slice validates the architecture against reality.
5. Top-down review
Does the whole thing cohere? Are invariants maintained?
Is the data model still correct given what was discovered?
The spike in step 2 is the Plan B method: build the simple version before you design the clever one. The vertical slices in step 4 are continuous bottom-up validation of the top-down decisions made in step 3.
| Practice | Mode | Why |
|---|---|---|
| Plain English requirements | Top-down | Frame the problem before the solution space |
| Invariants | Top-down | State what must be true before building the mechanism |
| Data modeling | Top-down first, bottom-up to validate | Schema reflects the domain; queries validate the schema |
| State machines | Top-down | Enumerate every state before coding the transitions |
| Plan B first | Bottom-up | Working code before clever code |
| Characterization tests | Bottom-up | Capture what the system does before you change it |
| Vertical slices | Synthesis | Top-down scoping, bottom-up delivery |
The diagnostic
When you’re stuck, ask which mode you’ve been in too long. Stuck in top-down means you’re designing but not building. Ship the Plan B. Make something run. Stuck in bottom-up means you’re building but not converging. Step back and ask the completion test question: what would “done” actually look like?