Extract the Engine: Why Shared Infrastructure Should Come Last
Updated
Knowledge on this page was mainly distilled from You Didn't Choose One Market. You Could Only Afford One..
After learning that one engine can support many focused products, the temptation is to open a terminal and start designing the shared infrastructure you will obviously need someday. This is the worst possible move.
Why Building the Engine First Fails
You do not know the future. You are currently thinking about your first product. Anything you build for the second one right now is a forecast wearing the costume of infrastructure. Premature shared systems encode guesses about which behavior will actually be common across products, and those guesses are almost always wrong in ways you cannot see until you have built the products they are supposed to serve.
The Correct Sequence
Build the first product end to end, with its logic sitting wherever it is convenient and no shared anything. When the second product arrives, resist the urge to extract. Build it standalone as well, exactly the way you built the first one. Let them sit side by side, with duplication intact.
Now look at them. You can see, from real running code rather than speculation, what actually repeated and what only looked like it would. Extract that, and only that, into a shared layer. The engine you end up with is one whose contract was written by two real products, not by a diagram you drew before either existed.
Why the Duplication Phase Matters
The duplication between products one and two is not waste. It is the period during which you discover what the engine's contract should actually contain. Premature abstraction locks you into an interface shaped by imagination rather than evidence. The cost of carrying temporary duplication is almost always lower than the cost of building shared infrastructure around the wrong seams.
This sequence also prevents a subtler failure: building an engine so general that neither product above it feels like it was designed for anyone in particular. Products shaped by real audience needs, then extracted into a shared system, produce an engine that serves those needs. An engine designed in advance produces products shaped by whatever the engine made convenient.
Q&A
How many products should exist before extracting a shared engine?
Two. The article recommends building the first and second products standalone, then extracting what genuinely repeated. Two real products give you enough evidence to see true commonality. One product gives you only guesses about what a second one would need.
Is this just the 'Rule of Three' from software engineering?
It is related but framed differently. The Rule of Three says to refactor after three instances of duplication. This advice is about the product and business layer: do not build shared infrastructure until two real products show you, through running code, where the actual shared behavior lives.
What if the duplication between products introduces bugs?
Temporary duplication does carry risk of inconsistency between the two products. But that risk is lower than the risk of premature abstraction, which locks you into the wrong shared interface. The duplication phase is short and intentional, not a permanent architecture.
Does this apply if I already know my second market well?
Yes. Even strong intuition about a second market does not reliably predict which implementation details will actually be shared versus which will diverge. Real code reveals seams that planning cannot. The recommendation is to build both products before extracting, regardless of confidence.