The Architectures You Need Depends on the Questions You Can't Afford to Get Wrong

A founder once asked me, “What’s the best architecture for a fast-scaling SaaS company?”

My answer?

It depends.

(Not because I'm being vague—because I am being honest.)

Architecture isn’t a best-practice checklist.

It’s a bet. And the quality of that bet depends on the questions your system needs to answer reliably and fast.

I will start with three:

1. What breaks when you double usage tomorrow?

If the answer is “the database,” prioritize data partitioning and observability.

If it’s “customer support,” rethink async flows, self-healing, and smart retries.

2. What happens if a deploy goes sideways on a Friday?

If it takes hours to roll back, you’re missing progressive delivery and a real CI/CD pipeline.

If no one knows it broke, you’re missing monitoring that talks to people, not just dashboards.

3. What changes often—and what needs to stay rock solid?

Architect for change at the edges. Lock stability at the core.

That’s how you stay fast and sane.

I’ve seen startups over-invest in microservices when all they needed was a modular monolith.

I’ve also seen companies build brittle monoliths when they should’ve abstracted a high-churn domain.

It’s not about trendy architectures.

It’s about fit-for-purpose decisions with just enough future-proofing to stay flexible.

Architecture is a leadership decision.

It reflects your risks, your constraints, and your product bets.

Get that part right, and you earn speed.

Don’t copy architectures from billion-dollar companies solving billion-user problems. Copy the thinking that helped them get there.

The Baseline