Why I Prototype Before I Propose

I've sat through hundreds of architecture review meetings. The ones that go well have one thing in common: someone built a prototype first.

The ones that go badly? They're usually 90 minutes of debating abstract diagrams, arguing over theoretical edge cases, and leaving with more questions than answers. Everyone has opinions. Nobody has evidence.

That's why I adopted a personal rule early in my career: never propose an architecture I haven't prototyped.

Diagrams Lie (Gently)

I'm not against architecture diagrams. I use them all the time. But they have a fundamental limitation: they show what you intend to build, not what you can build.

A diagram can show a clean service boundary. It can't show you that the network latency between those two services makes the design impractical. A diagram can show an event-driven pipeline. It can't show you that the message ordering guarantees you assumed don't actually exist.

Prototypes reveal the truths that diagrams conceal.

What a Good Prototype Looks Like

A good prototype isn't a mini version of the final system. It's a focused experiment designed to answer specific questions:

• "Can we achieve the required latency with this architecture?"
• "Does this database handle our query patterns efficiently?"
• "Can these two services communicate reliably using this protocol?"
• "Does this library actually work the way the documentation claims?"

The prototype should be disposable. Build it quick, learn from it, throw it away. The value is in the learning, not the code.

I typically spend 2-3 days on a prototype, which sounds like a lot until you compare it to the weeks or months you'd spend building the wrong architecture.

The Proof-of-Concept Checklist

Before I present a technical direction, my prototype needs to answer:

Feasibility. Can the thing I'm proposing actually work? Not in theory — in practice, with real tools, real data, and real constraints.

Performance. Does it meet the performance requirements? I run basic load tests against the prototype. Nothing fancy — just enough to validate that the approach is in the right ballpark.

Complexity. How complicated is the implementation? A beautifully simple architecture that's nightmarishly complex to implement isn't a good architecture.

Operational concerns. How will this run in production? What does monitoring look like? What happens during deployment? The prototype should surface operational questions that pure design work misses.

Selling the Approach

When I present a technical direction to stakeholders, the prototype changes the conversation entirely. Instead of "I think we should..." it becomes "I built a prototype that demonstrates..."

The conversation shifts from opinion to evidence. Concerns shift from theoretical to practical. Decisions get made faster because there's concrete data to evaluate.

I've had proposals that I was personally excited about get killed by the prototype — the performance wasn't there, or the complexity was too high, or an assumption turned out to be wrong. Every time, I was grateful the prototype caught it early rather than discovering it in production.

When Not to Prototype

I don't prototype everything. If the approach uses well-understood patterns with known performance characteristics, a design document is sufficient. If the team has built similar systems before, the unknowns are minimal.

Prototyping is most valuable when:

• You're using technology the team hasn't used before
• Performance requirements are tight and uncertain
• The architecture involves novel integration patterns
• The stakes of choosing wrong are high

The Two-Day Investment

Two days of prototyping can save months of rework. It sounds obvious, but the pressure to "start building" often overrides the instinct to validate first.

Resist that pressure. Build the prototype. Let it tell you the truth. Then propose with confidence.