Scaling architecture: enough is optimal

The most common technical mistake in scaling companies isn't buying the wrong tool — it's treating "designed for 10×" as a virtue. The goal of architecture is never completeness; it's letting the next stage of the business actually run.

Three test questions

• Does this system solve today's bottleneck, or an imagined one?
• Will migration cost eat two quarters of engineering capacity?
• When it breaks, can someone on the team locate the fault within a day?

We recommend "good for 12 months" as the default bar: if a solution can safely carry the next 12 months of growth, ship it, and save the complexity for scale that actually arrives.

When to over-invest

Data models and permission systems deserve forward design — their rework cost is exponential. Almost every other choice should lean simple.