When to Build Shared Infrastructure (and When Not To)
A decision checklist for when to build shared infrastructure versus copy per project, based on ship frequency, overlap, and the maintenance tax you can carry.
Build shared infrastructure when you will ship enough products, sharing enough of the same plumbing, that the reuse discount outruns the maintenance tax. Skip it when you will not. That is the entire decision, and most teams get it wrong by building a platform for a portfolio they do not have yet, or by copy-pasting forever across a portfolio that clearly needs one. Here is the checklist I actually run before anything goes into the shared core.
How often will you ship new products
Shared infrastructure is an investment that pays back per product. The first product pays full price to build the foundation and gets no discount. The second reuses it. The third barely notices the plumbing. If you are going to ship one product every three years, you will never get to the volume where the discount shows up, and the ongoing cost of maintaining a shared core will bury you.
I ship often, which is why the foundation pays for me. It is the mechanism behind each next venture being cheaper to ship. If your roadmap has one product on it, copy what you need and move on. Do not build a platform for an audience of one.
How much do the products actually overlap
Shared infrastructure only helps where products are genuinely the same underneath. Auth, billing, deploy, logging, and the base data layer are usually identical across products, so they are prime candidates. The differentiated product logic, the thing a customer pays for, is not shared and should never be forced into a common shape.
Run the honest audit. List what your next three products need, and mark what is truly identical versus what only looks similar. If the overlap is thin, a shared foundation will spend most of its effort abstracting things that did not need abstracting. If the overlap is thick and boring, that is exactly what belongs in one governed foundation under every company. Thick and boring is the sweet spot.
Can you carry the maintenance tax
A shared foundation has a running cost that a copy-paste does not. Every change touches multiple products, so every change needs versioning, deprecation notices, and scripted migrations. If you cannot commit to that discipline, a shared core turns into the thing everyone works around, and you get fragmentation plus overhead, the worst of both.
Be honest about capacity before you commit. The tax is real and permanent. I pay it because the reach is worth it and because I keep foundation changes cheap to ship by running them through the same spec-driven development loop I use for products, with Bootspring turning specs into tested increments. If you have no way to make shared-core changes safe and fast, do not sign up for the reach that makes unsafe changes catastrophic.
Does governance push you toward sharing
Sometimes the deciding factor is not speed at all. If your products carry audit, security, or compliance requirements, you want those rules implemented once and inherited everywhere, not reimplemented per product by whoever built it. Reimplemented governance drifts, and drifted governance fails the moment a buyer or regulator inspects it.
When compliance is on the line, the case for shared infrastructure gets stronger even at lower product volume, because the alternative is not just slower, it is inconsistent in a way that costs you deals. Uniform enforcement is a feature you can sell, and it only exists when the rules live in one place.
The rule I use
Build shared infrastructure when three things are true: you will ship products often, they share thick and boring plumbing, and you can carry the versioning discipline. Add a fourth reason, uniform governance, and you can justify it at lower volume. Miss on ship frequency or overlap, and copy per project instead. There is no shame in copy-paste for a small portfolio, and there is no glory in a platform nobody but its author will ever use.
The mistake is treating shared infrastructure as automatically virtuous. It is a leverage play, and leverage only pays when you use it repeatedly. Decide from your real roadmap, not the one you wish you had, and build the foundation only when the arithmetic actually closes.