Does a Shared Foundation Slow You Down? Not If Built Right

The objection is fair: a shared foundation can absolutely slow you down. When it is built wrong, every product waits on the shared core, every change needs a committee, and the abstraction fights the thing you are trying to build. But that is a symptom of a bad foundation, not proof that foundations are bad. Built right, the shared core is the reason a new product ships in days instead of months. Here is how to tell which one you have.

When a shared foundation actually drags

A shared foundation slows you down in three specific situations, and they are worth naming because they are all fixable.

First, when the abstraction is wrong. Someone hoisted a pattern into the foundation before it had proven itself across products, and now every product bends around a shape that fits none of them. This is premature abstraction, and it is the most common cause of foundation drag.

Second, when everything routes through a bottleneck. If any product change requires a change to the shared core, and only one person can approve those, the foundation becomes a queue. Products wait on each other for no reason. The core should be stable enough that most product work never touches it.

Third, when the foundation leaks product logic. Once unrelated products are coupled through the shared core, a change one needs risks breaking others, so every change gets slow and scary. That is coupling masquerading as reuse, and it is the exact opposite of what a foundation is for. I wrote about this failure mode in the mistakes that turn a shared foundation into dead weight.

Why the right foundation is an accelerator

Now the other side. When the foundation is built right, it is the single biggest reason my products ship fast. A new venture inherits auth, billing, deploy, and logging on day one and never rebuilds them. The team, or in my case just me, spends its time on the part that is actually new. That is not a tax, it is a head start.

The measure is simple. On the third product, how much of the work is plumbing versus the actual product? With a good foundation, almost all of it is the product, because the plumbing is inherited. That is the whole point of building each next venture cheaper. Speed on venture three is bought by the foundation you paid for on venture one.

How to keep the shared core fast

Three rules keep my foundation an accelerator instead of a brake.

Keep it boring and stable. The foundation handles the identical plumbing and nothing product-specific. Because the differentiated work lives per venture, most product changes never touch the shared core, so there is no bottleneck to wait on. Stability at the base is what lets you move fast at the edges.

Wait for two cases before abstracting. Nothing goes into the foundation until a second product genuinely needs it. This kills wrong abstractions before they slow anyone down, because you only generalize patterns that have actually repeated.

Make shared changes cheap and safe. When the core does need to change, the change ships with a spec, tests, and a scripted migration, not a hopeful commit. I run those through the same spec-driven development loop as product work, with Bootspring turning the spec into a tested increment. Fast, safe changes to the core mean the foundation never becomes the thing people fear touching.

The honest tradeoff

You do pay more on any single shared change than a copy-paste would cost, because more things depend on it. That is the real tradeoff, and it is worth being upfront about. You buy that cost back on every new product that inherits the work for free. If you ship often, the trade is obviously good. If you rarely ship, the per-change cost dominates and the copy-paste wins.

So the objection has a real answer. A shared foundation slows you down when it is wrong, coupled, or bottlenecked. Fix those and it does the opposite. The foundation is not inherently drag or acceleration. It is whichever one you built.