Three-Horizon Architecture Test: Design for Year 1, 2, and 5

Most architecture decisions are tested against a single load profile: the one the system will face on day one. That is the cheapest moment to validate, and so it is the moment teams default to. The decision passes. The system ships. Two years later, the same decision has become the bottleneck the entire roadmap is trying to engineer around — and now the cost of changing it is measured in quarters of rebuild, not weeks of design.

The Three-Horizon Architecture Test™, a component of EB Pearls' Built to Last™ 2.0 framework, exists to stop that pattern at the moment it can still be stopped cheaply. Before any architecture decision is locked, the design is evaluated against three horizons: today's build, 10× scale, and the business in three years. A decision that passes today but fails at 10× is not locked. A decision that passes 10× but breaks the year-five business model is not locked. Only decisions that pass all three horizons go into the Architecture Decision Record.

This article is a decision guide. It walks through how the test runs in practice, the trade-off matrix it produces, the categories of decision it most often catches, and the rules of thumb for choosing between competing architectures. It sits alongside the Architecture Session, which is where the test is most often applied; this piece is the conceptual companion that explains what passing all three horizons actually means.

What Goes Wrong When You Only Test for Today

Architecture decisions are sticky. The cost of changing a data model after launch is the cost of every dependent feature, every analytics pipeline, every customer integration that was built on top of the original shape. The cost of changing a tenancy model is the cost of every operational tool, billing flow, and support process that assumed the original answer. The cost of changing a primary database engine is, in practice, the cost of a rewrite.

A team that tests its architecture against only today's load is not being negligent. They are doing what the project plan asks. The brief says "ship the MVP for the first hundred users". The system handles a hundred users. The architecture review confirms it. The decision is locked. Months later — sometimes a year, sometimes three — the same architecture is being asked to handle a thousand users, then ten thousand, then a different shape of workload entirely. The decision that was correct against horizon one is wrong against horizons two and three. The team did not get the question wrong. They were asked the wrong question.

The cost shows up in three places. Velocity slows because every new feature has to work around the original constraint. The roadmap shrinks because the team becomes reluctant to touch certain areas. And the rebuild conversation arrives — quietly at first, then unavoidably — when leadership notices that adding capability is now taking three times what it used to. None of this is visible at the moment the original decision was made. It compounds invisibly until it is structural  (custom software development) .

The Three Horizons, Defined

The test has a deliberately simple structure. Three horizons. Three questions. A decision must pass all three to be locked.

Horizon 1 — Today. Does the architecture support the build as it will exist at first launch? Volume, latency, integrations, team size, operational maturity. The horizon-one test is the one teams instinctively run. It catches the design that cannot ship.

Horizon 2 — 10× scale. Does the architecture still hold at ten times today's load, traffic, data volume, or transaction rate? The 10× multiplier is deliberate. It is large enough to expose hidden coupling, but small enough that any product that succeeds will plausibly reach it. The horizon-two test catches the design that ships but breaks under success.

Horizon 3 — The business in three years. Does the architecture still support the business's likely shape three years out — different customers, different product surface area, different regulatory posture, possibly different geography?  (GitHub Octoverse report on language and ecosystem evolution ). Three years is not a forecast; it is a stress test against plausible direction. The horizon-three test catches the design that handles scale but locks the business into the wrong shape ( Transforming a product idea into something that scales globally) .

A decision that passes all three is locked into the Architecture Decision Record with the reasoning visible. A decision that passes today but fails at 10× is reconsidered before it is locked. A decision that passes today and 10× but fails the year-five test is held open: it may still be the right answer, but only with an explicit migration path documented from the start.

The Trade-Off Matrix

The three horizons rarely point to the same answer. The discipline of the test is in making the trade-off explicit, not in pretending there is a single correct architecture that satisfies everyone.

The matrix evaluates each candidate architecture along three rows (the horizons) and three columns: technical fit, operational cost, and exit cost. Technical fit is whether the architecture can do the job. Operational cost is what it costs to run. Exit cost is what it would cost to change later if the horizon was misjudged.

A monolith may score strongly on horizon one for technical fit and operational cost. At horizon two, the technical fit weakens — the same monolith struggles to scale specific components independently. At horizon three, the exit cost is high because by then it has accreted three years of dependent code. A modular monolith with event-driven hooks may score slightly lower on horizon-one operational cost but holds its technical fit through horizon two and keeps the horizon-three exit cost manageable (  AWS Well-Architected Framework ).

The matrix's job is not to declare a winner. It is to make the choice visible. A team that chooses the monolith after running the matrix is making a different decision from a team that chooses it because nobody asked the question. The first decision can be revisited deliberately when the horizon-two signals appear. The second cannot, because the team has no shared record of what they assumed.

This is the structural value of the test. The horizons themselves are not magic. The discipline of comparing candidate architectures against them is what catches the decision before it is locked.

Categories of Decision the Test Most Often Catches

Five categories come up repeatedly across product engagements. They are the decisions where horizon-one thinking most reliably misleads.

Tenancy model. Single-tenant versus multi-tenant. The horizon-one answer is often single-tenant because the first customers want isolation and the engineering is simpler. The horizon-two and horizon-three answers usually argue for multi-tenant with strong isolation guarantees, because operational cost per tenant scales linearly with single-tenant and the team cannot serve a hundred customers the way they served three.

Data model boundaries. The shape of the core entities and the relationships between them. Horizon-one optimises for the first feature set. Horizon-two and horizon-three need a model that survives entities the team has not yet imagined. The test catches the case where today's entity shape will require a multi-table migration the moment the second major feature arrives.

Synchronous versus event-driven flows. Most workflows are simpler synchronous on horizon one. Some of them collapse at horizon two because they assume a third-party dependency that becomes unreliable under load. The test asks whether the workflow needs to be event-driven by design or whether synchronous is genuinely durable across all three horizons  (how we deliver mobile apps) .

Compute model. Containers, serverless, virtual machines, edge. Horizon-one cost favours whichever the team already knows. Horizon-three cost favours whichever the workload actually fits. The test forces the comparison rather than letting team familiarity decide ( Stack Overflow Developer Survey on technology evolution and adoption ).

Authentication and identity. Horizon-one identity is usually a single product, a single user pool, and one role tier. Horizon-three identity often involves enterprise customers, single sign-on, federated identity, and granular role permissions. Choosing the horizon-one identity model without thinking about horizon three is one of the more expensive mistakes a product can make.

Rules of Thumb for Choosing Between Architectures

When the matrix surfaces a trade-off, four rules help resolve it.

A Composite Scenario

A SaaS product we worked with at the Scale stage had launched with a single-tenant architecture. The first three customers had wanted isolation. The engineering team had built what was asked: a fully isolated stack per tenant, provisioned through infrastructure-as-code, with separate databases, application instances, and observability per customer. At horizon one, the architecture passed every test. The customers were happy. The team shipped.

At fifty customers, the wall appeared. Each tenant required a fixed operational cost to monitor, upgrade, and support. The infrastructure bill scaled linearly. So did the on-call burden. So did the time to ship a feature across the fleet — every release had to be validated against fifty environments rather than one. The team had not got the engineering wrong; the architecture worked exactly as designed. What had been wrong was that horizon two and horizon three had never been tested at the moment the decision was locked.

A three-horizon review would have surfaced the trade-off directly. Single-tenant scored well on horizon one for technical fit and customer comfort. It scored poorly on horizon-two operational cost the moment customer count moved past a small number. It scored worst of all on horizon-three exit cost, because the team's operational tooling, billing, and support were all built on the single-tenant assumption. A multi-tenant architecture with strong isolation guarantees — the same audit and data-residency promises that the first three customers actually cared about — would have passed all three horizons. The eventual rebuild took a year. A three-horizon test at design would have taken a day  (common rookie mistakes when choosing a development partner) .

When the Test Is Critical, When You Can Move Faster

Run the full three-horizon test for every architectural decision that will be expensive to change later. Tenancy model, primary data model, identity, primary database engine, compute model, and the boundary between modules and services. These are the decisions whose horizon-three exit cost is highest and where horizon-one thinking most often locks in the wrong answer.

Where you can move faster: decisions that are genuinely reversible at low cost. The choice of a UI component library, the specific deployment target within a cloud, the structure of a non-core service that can be rewritten in a sprint. The three-horizon test is not free, and applying it to every micro-decision drains the team's design budget. Apply it where the exit cost would be measured in quarters or years, not in hours.

If you are at the MVP stage and the product has not yet found its first customer, horizon three is mostly hypothetical. Test against today and 10×, and document the horizon-three assumptions explicitly so a future team can revisit them when there is real signal to test against. The discipline is in writing down what you assumed, not in pretending you can forecast three years.

What to Do Next

For the next architecture decision you are about to lock, run the matrix. Three horizons across the rows, technical fit, operational cost, and exit cost across the columns. Score each candidate explicitly. Choose the architecture that passes all three horizons, or lock a horizon-one-and-two answer with the horizon-three migration path documented. To see how the matrix is run inside a structured design session, read how we deliver custom software end to end.

Frequently Asked Questions