Universal Foundation First

The trap

You build something. It works. The obvious next move is to build the next one like it. So you do, and the second one shares most of its structure with the first, except now that structure exists twice, drifts in two places, and has to be fixed in two places. Build a third and the duplication compounds. This is how a product family turns into a maintenance burden that caps how many verticals you can actually run.

The trap is seductive because each individual build feels productive. The cost is invisible until you are maintaining the same logic in three slightly different forms.

The discipline

Before you build vertical number two, do three things in order:

1. Extract the foundation from vertical one. Find the part that is not specific to that vertical, the chassis that any instance would need, and pull it into a shared module.
2. Prove it by reuse. Re-integrate the extracted foundation back into vertical one. If the thing you built still works on top of its own foundation, the foundation is real. If it does not, you learned that cheaply, on a project that already exists, instead of on a new one.
3. Then spawn vertical two as a thin layer. Now the second vertical is the small amount of code that is genuinely specific to it, sitting on a foundation you have already validated.

Why the order matters

The instinct is to build the foundation speculatively, up front, before you have a single working instance. That fails the other direction: you abstract for needs you have only guessed at, and the abstraction is wrong in ways you cannot see yet. Universal Foundation First waits until you have exactly one working vertical, so the foundation is extracted from something real, not imagined. One instance is enough signal to find the shared shape. Zero is not.

So the rule is neither "duplicate freely" nor "abstract early." It is: build one, extract from the one, prove the extraction, then scale. The foundation earns its existence by surviving reuse before it is ever asked to support something new.

The tell

The recognition signal is the same as for the Pre-Execution Audit, and the two often fire together. When you catch yourself saying "the obvious next move is another one like this," stop and ask whether you are about to build a parallel vertical or a thin layer on a shared foundation. The answer changes how much code you write and how much you will have to maintain forever.