Is Your Shared Foundation Paying Off? Metrics to Check
How do you know a shared foundation is paying off? Track time-to-first-deploy, per-product maintenance, and foundation reuse. Here are the metrics that prove it compounds.
A shared foundation is supposed to compound: each new product cheaper than the last, each operational task written once, the whole portfolio getting easier to run as it grows. But "supposed to" is not proof. Plenty of foundations quietly stop paying off and become the thing everyone tiptoes around instead. So measure it. There are a handful of concrete metrics that tell you whether your foundation is actually compounding or slowly turning into a liability. If you cannot point to these numbers moving the right way, your foundation is a story you are telling yourself.
How do I know if my shared foundation is working?
Watch whether new products get cheaper and existing products get easier to maintain, over time. Those two trends are the entire promise. If both are true, the foundation is compounding. If either has stalled, something is broken. Here are the specific things to track.
Time to first deploy for a new product. This is the headline number. How long from "I want to build product X" to "product X is live with auth, billing, and a deploy pipeline"? If your foundation works, this number falls as your portfolio grows, because more of the plumbing is already solved. If it is flat, your foundation is not actually reducing per-product work. It should trend toward spinning up a new app in a day.
Per-product maintenance load. Roughly how much of your time goes to keeping each existing product running? In a compounding foundation this falls per product, because one runbook covers all of them and fixes apply everywhere at once. If maintenance load grows linearly with product count, your products have diverged and the foundation is not amortizing operations.
The reuse ratio nobody tracks
Here is a metric people never measure but should: what fraction of a new product is inherited versus built fresh? Call it the reuse ratio. When you ship a new product, estimate how much of it came from the foundation and how much you wrote from scratch.
A healthy foundation pushes this ratio up over time. Early products might be 30 percent inherited. By the tenth product it should be well over half, because the foundation has absorbed everything that repeats. If the reuse ratio is not climbing, you are re-solving problems you already solved, which means the marginal cost of the next product is not falling the way it should.
The inverse metric is just as telling: how often do you copy-paste the same solution into a new product instead of inheriting it? Repeated copy-paste of the same thing is a signal that something belongs in the foundation and has not been promoted yet. A little of this is fine and healthy under the rule of three. A lot of it means the foundation is lagging behind what your products actually share.
The warning signs a foundation has stopped paying off
Some metrics are negative. They tell you the foundation has crossed from asset to liability.
- Fear of changing the foundation. If you avoid touching the shared layer because you are not sure what it will break, the foundation has become a bottleneck instead of leverage. The fix is testing the foundation against every consumer so changes are safe again.
- Foundation changes that break products in production. If shared-layer edits regularly cause incidents, your versioning or testing discipline has failed. A working foundation changes often and calmly.
- Products routing around the foundation. If new products increasingly ignore the shared layer and do their own thing, the foundation has become a straitjacket, and you have drawn the standardize-versus-diverge line in the wrong place.
- Rising per-product maintenance. The clearest sign of divergence, and the clearest sign the amortization has broken.
Any one of these means stop and fix the foundation before adding products, because a foundation that is not paying off makes every new product worse, not better.
Measure it because the failure is silent
The reason to track these numbers is that a foundation fails quietly. Nothing announces "your foundation stopped compounding." Products just gradually get slower to build and harder to maintain, and if you are not measuring, you attribute it to bad luck or complexity instead of a foundation that drifted.
I keep an eye on time-to-first-deploy and reuse ratio directly, because my build platform scaffolds new products against the foundation and shows me how much is inherited, so Bootspring makes the compounding visible instead of assumed. If the numbers are moving the right way, the foundation is doing its job and every new product proves it. If they stall, that is the signal to invest in the foundation again before the hidden cost of divergence creeps back in. A foundation is not a thing you build once and trust forever. It is a thing you measure, so you know it is still paying you.