The system nobody used…
Eighteen months! That’s how long it took to build the platform “right?”
Event-driven from day one.
A service mesh before we had a second team to justify one.
Multi-region active-active, because “what if we need to scale globally.”
A schema flexible enough to absorb business models we hadn’t even conceived of yet.
Every design review ended the same way: someone asking “but what if we need to handle 10x?” and the room nodding along, because who wants to be that person who didn’t plan for scale?
We shipped a cathedral. But what the business needed was a tent.
And the part I don’t love admitting: I was one of the people nodding along in that room. Nobody forced this on us. We talked ourselves into it, one reasonable-sounding “what if” at a time.
Eighteen months after launch, the product had pivoted twice -
The multi-region setup we’d sweated over never saw traffic outside one data center.
The event bus we’d designed for massive throughput was carrying a few hundred messages a day — quiet enough that on-call engineers joked about hearing crickets.
The flexible schema, built to absorb business models we never ended up building, sat there as unused columns and
forgotten migration paths, a monument to a future that didn’t arrive.
We hadn’t built a system. We’d built an insurance policy against a future we guessed at — and paid for that guess in the currency that matters most in this industry which is - Time.
Eighteen months we didn’t get back, in a market that moved on without waiting for us.
We built for a future that never showed up. That’s the sentence that kept nagging at me long after the project wrapped. And it forced an uncomfortable admission: we weren’t really doing architecture. We were trying to predict the future — and dressing those predictions up in diagrams to make them feel like engineering.
Why we keep calling it a Blueprint?
We inherited the word “blueprint” from construction, and it’s a seductive metaphor — precise, complete, drawn before a single brick is laid. A blueprint implies that if you think hard enough up front, you can specify the final state, and execution becomes a matter of following the plan.
Buildings can work this way because they operate inside constraints that hold still. Gravity in 2026 behaves exactly like gravity in 1926. The ground doesn’t pivot to a new business model six months into construction.
Software systems don’t get that luxury. The market shifts. Competitors ship something that changes what “table stakes” means. A regulation appears. Someone in the C-suite reads an article about AI agents and suddenly the roadmap has a new top priority. Your blueprint was accurate the day you drew it, and it started decaying the moment ink hit paper.
Yet we keep architecting as if the ground will hold still. We produce artifacts — the diagrams, the ADRs, the sprawling design docs — that read with the same false confidence as a building’s structural plan, describing a future we don’t actually know.
When was the last time you saw an architecture doc that admitted, in writing, “we’re not sure about this part”? I can’t remember the last one I wrote that did either.
The tell is in the language itself. Nobody asks “what did we bet on in Q2?” in an architecture review. They ask “did we follow the design?” That question only makes sense if you believe the design was knowable in advance. Which, usually isn’t.
The Reframe: Architecture is a Bet !
Here is the model that’s actually stuck with me since - the one I keep coming back to whenever a design review starts sounding a little “too certain”: every consequential architectural decision is a bet on the future.
Not every decision qualifies, to be fair —
some are constraints you don’t get to choose,
some are pure engineering hygiene with no real uncertainty attached.
But whenever we’re choosing an architecture in the face of an unknown future, we’re making a bet. We just usually don’t call it that.
A bet has a few characteristics that a blueprint doesn’t. Once you start looking for them, you can’t unsee them in every design conversation you sit in.
The 5 properties of an Architectural Bet !
1. Thesis — what are we betting will happen? When you choose event-driven over synchronous, multi-region over single-region, build over buy — you’re not deriving the correct answer from first principles. You’re staking resources on a specific belief about what the future needs. Naming the thesis out loud is the first discipline blueprint-thinking skips.
2. Confidence — what evidence makes us believe it? Good architects don’t ask “is this the right design?” — an unanswerable question about an unknowable future. They ask “given what we actually know, how confident are we in this thesis?” That’s a fundamentally different, and more honest, conversation than the one most design reviews have.
3. Size — how much complexity, time, and money are we willing to commit? You don’t bet your whole stack on a guess about hypothetical scale. Size the bet to the confidence you have, not to the worst case you can imagine. Low confidence, small bet: a lightweight event log instead of a full mesh, a modular monolith instead of a microservices platform you don’t yet have the team to run. High confidence — you’ve seen this pattern before, the signal is strong — size up.
4. Optionality — how expensive is it if we’re wrong? A good bet doesn’t require certainty. It requires a way to survive being wrong — that’s what optionality is for. The less certain we are, the more valuable it is to preserve our ability to change direction. A modular monolith preserves the option to extract services later. An abstraction around a vendor preserves the option to switch providers. A migration path left open prevents today’s decision from becoming tomorrow’s trap.
5. Review trigger — what evidence would cause us to change course? Nobody re-litigates a blueprint once it’s approved — that’s the point of a blueprint, its authority comes from being settled. A bet, by contrast, is supposed to be revisited as new information arrives. You don’t abandon it at the first sign of trouble, but you also don’t treat “we already decided this” as a reason to keep doubling down on a losing position.
Now, let’s go back to my eighteen-month build.
Every “what if we need 10x” question was really an unsized, unhedged, never-revisited bet — and none of us in that room named it as one.
And now, let’s run the same conversation through the five properties instead, and see - it plays out completely differently: What’s the thesis, exactly? What’s our actual confidence that we hit that scale in the next 12 months? What’s the smallest version of this decision that preserves optionality if we’re wrong? What would tell us to reconsider? That’s a different meeting, totally. Honestly, I wish someone had asked it in ours.
Architecture isn’t about maximizing the odds you’re right
It’s about minimizing the cost of being wrong.
If a decision is cheap to reverse, you don’t need much certainty before making it. If it’s expensive to reverse, you should demand real evidence before committing.
This is the same logic Amazon built into its “one-way door / two-way door” framing for decision-making: some decisions are two-way doors — cheap, fast, reversible, you can just walk back through. Others are one-way doors — expensive, disruptive, sometimes impossible to undo. The more irreversible the architectural decision, the more evidence it deserves before you commit.
That gives you a decision mechanism, not just a philosophy. Instead of asking “could this happen?” — a question almost anything passes — ask three questions together: What’s the probability this actually happens? What does it cost us if we’re wrong? What does it cost us to prepare for it right now?
A low-probability, high-preparation-cost bet (full active-active multi-region for traffic you don’t have yet) rarely clears the bar.
A cheap hedge against a plausible near-term risk (an event contract that costs you an afternoon) almost always does.
What this looks like in practice?
Microservices:
Thesis: “we’ll probably need independent scaling.”
Confidence: maybe 30%, mostly speculative.
Bet: a modular monolith with strong internal boundaries, not a service mesh.
Optionality: boundaries clean enough to extract services later.
Review trigger: real scaling pressure or real team-boundary friction — not a hunch.
Multi-region:
Thesis: “we might become globally distributed.”
Confidence: maybe 15%, no signal yet.
Bet: design for portability — keep infrastructure choices from locking you into one region, without paying for active-active yet.
Optionality: swapping in a second region later is a project, not a rebuild.
Review trigger: an actual customer on the other side of the world, not a hypothetical one.
Event-driven integration:
Thesis: “future teams will need to integrate asynchronously.”
Confidence: maybe 60% — this one’s more likely than the others.
Bet: establish clean event contracts now, on lightweight infrastructure.
Optionality: contracts are portable to a heavier platform later; today's plumbing isn't load-bearing.
Review trigger: message volume that actually justifies running a dedicated streaming platform, not the possibility of it.
Same underlying uncertainty, three very different bet sizes — because the confidence, and the cost of being wrong, are different in each case.
What changes when you architect like a “Bettor”?
This isn’t an argument for recklessness or for skipping analysis — bets built on no evidence are just gambling, and gambling isn’t what good architects do. It’s an argument for running the five-property discipline on every consequential decision:
State the thesis. Say what future you’re betting on, explicitly, in the room where the decision gets made.
Record the evidence and your confidence. Not “what if” — what do you actually know, and how sure does that make you?
Size the investment to the confidence. Low confidence gets a small, cheap bet. High confidence earns a bigger one.
Preserve optionality when uncertainty is high. Pay for reversibility in proportion to how unsure you are — and stop paying for it once you’re not.
Define what would change your mind. Put a review trigger on the bet before you make it, not after it’s already failing.
The thing though is— our eighteen-month cathedral wasn’t a failure of technical skill. Everyone in that room was smart, experienced, and genuinely trying to do right by the business, myself included. The real failure was capital allocation: we committed eighteen months of scarce engineering capacity to a future that hadn’t earned it. Architects aren’t only choosing technologies. We’re deciding where an organization spends its complexity, its engineering time, its attention, its future flexibility. That’s a much bigger job than picking the “right” pattern off a slide.
Architecture was never really about knowing the future. It’s about allocating resources wisely when you don’t. We don’t need architects who can predict what happens next — nobody can — we need ones who make good decisions when the future, inevitably, refuses to cooperate.
So next time someone asks “did we follow the design?” — try a different question instead: what did we bet on, how big, what happens if we’re wrong, and what would make us change our mind? See how different the room feels.
Keep this in mind:
Thesis — what future are we betting on?
Confidence — what evidence actually supports it?
Size — how much are we willing to invest, given that confidence?
Optionality — how do we survive being wrong?
Review trigger — what evidence would make us change course?
A template worth stealing for your next ADR:
We believe: [thesis] Because: [evidence] Confidence: [rough %] We’re investing: [size/scope of the bet] If we’re wrong, it costs us: [cost of reversal] We’ll reconsider when: [review trigger]