Multi-Surface Drift: The Forever Cost of Many Products on One Engine
Updated
Knowledge on this page was mainly distilled from You Didn't Choose One Market. You Could Only Afford One..
The strongest objection to a one-engine, many-surfaces strategy is not about building. It is about drift. Ten surfaces means ten places the same rule can be wrong. You will not learn which copy drifted from a test. You will learn it from a customer who got charged twice.
Why Drift Is the Real Threat
Generating a surface is a one-time cost. Keeping that surface honest against an engine that keeps changing is a forever cost. Every single change to the engine becomes ten separate opportunities for something to fall out of sync behind your back. Cheap to create, expensive to keep true, and that second cost shows up every week for years.
This asymmetry is what quietly killed multi-surface strategies long before any of this was AI-assisted. The build cost was the visible barrier, but the maintenance cost was the one that actually wore teams down. AI moved both numbers, but it moved the build cost far more dramatically than the maintenance cost.
What Helps and What Does Not
Thin surfaces carry less bespoke code that can rot. A surface generated from a canonical description of what the engine does can be regenerated against a changed engine for relatively little effort. That genuinely improves the arithmetic without making the problem disappear.
What does not help is the assumption that surfaces will stay thin automatically. Whether your surfaces remain thin is discipline rather than architecture. If presentation-layer code starts absorbing domain logic, permission checks, or pricing rules, each surface becomes a fork of your product that you did not intend to create. Nobody, including experienced practitioners of this strategy, can promise they will hold that discipline for four years running.
The Honest Assessment
If you will not maintain the discipline of keeping surfaces thin and logic centralized in the engine, the drift objection wins outright and you should be running one product. This strategy is only ever as good as the smallest amount of attention you are still willing to pay it in year three. The fun half is learning that surfaces are cheap to build. The half that determines survival is whether you can keep them honest over time.
Q&A
What kind of drift causes the worst problems?
The most dangerous drift is when a domain rule, such as pricing logic or permission checks, migrates into a surface layer instead of staying in the engine. You now have two sources of truth for the same rule, and they will diverge silently. You discover the problem from customer-facing errors, not from tests.
Can automated tests solve the drift problem?
Tests help but do not eliminate the risk. The issue is that you may not know what to test for until a surface has already drifted. Surfaces generated from a canonical engine description can be regression-tested against that description, but surfaces that accumulate ad hoc logic create test gaps you cannot see from the engine side.
How does AI help with maintenance specifically?
AI makes it cheaper to regenerate a thin surface against a changed engine specification. It also helps with test scaffolding and documentation updates. But it helps far less dramatically with maintenance than with initial creation, and anyone claiming the maintenance problem disappears entirely is selling the fun half only.
What is the 'year three' problem?
In year one, discipline is fresh and surfaces stay thin. By year three, small compromises have accumulated: a quick fix here, a surface-specific rule there. The strategy's viability depends on the minimum attention you are still paying to architectural discipline at that point, not the maximum attention you paid at launch.
Should I avoid this strategy if I cannot commit to long-term maintenance discipline?
Yes. The article is explicit: if you will not hold the discipline, the drift objection wins outright and you should run one product. One well-maintained product is better than several drifting ones, regardless of how cheap the surfaces were to build initially.