Eighteen months ago your platform group published a golden-path service template with logging, auth, deployment and dashboards already wired. 140 services now run on it, spread across six template versions. A security fix in the auth wiring has to reach all 140. What did the template buy, and what is the bill that just arrived?

What was gained

A default is decided once and applied every time a service is created, with no conversation. The template makes roughly eight to ten choices — log format, auth middleware, deploy pipeline, base image, metric names, health-check shape — so 140 services carry about 1,200 decisions nobody argued about. The alternative, a review per service, costs 140 meetings and produces less uniformity, because reviewers are inconsistent and tired.

That is real purchase, and it is why owning the defaults new services inherit is usually a higher-value use of an architect's week than reviewing designs. The effect is in the ratio: one decision, 140 applications.

What is being paid, and when the bill arrives

The bill arrives the first time a default has to change. A template that is copied at creation time — a scaffold — distributes code, and a fix to a scaffold reaches exactly zero existing services. You now need 140 pull requests across 26 teams, each competing with that team's own roadmap, and the slowest team sets the date for the whole fleet. Six live versions is the visible symptom: the estate has been drifting since month two and nobody measured it.

The property that decides the size of this bill is whether the template distributes copied code or a versioned dependency. A scaffold's patch cost is proportional to the number of services and is paid in other teams' attention. A dependency's patch cost is one release plus a fleet-wide version bump that one team can automate, raise and track.

The design that keeps both

Split the template along the line of who must be able to edit it:

1. Anything you will ever need to fix centrally must not be copied — auth middleware, TLS configuration, the logging transport, the base image. These ship as a versioned library and a versioned base image.
2. Anything a team must own and change — handlers, the service's configuration, its own code — ships as scaffold, copied once and never touched by you again.
3. Measure adoption as a distribution, not a mean. The numbers that matter are the share of services more than two versions behind and the age of the oldest version in production. A mean hides the tail that will block the next security fix.

What it costs

You now own an upgrade treadmill. Every breaking change in the shared dependency is paid 140 times, so the dependency's public surface must be deliberately smaller than the scaffold's — narrow it until a breaking change is rare, and version it so two majors can coexist for a quarter while teams move.

When this is the wrong answer

Below roughly fifteen services, or where teams genuinely run different runtimes and languages, the scaffold wins: the coordination cost of a shared dependency, its release process and its compatibility promises exceeds the cost of patching a handful of copies by hand. The flip condition is countable — when the number of services times the expected central fixes per year exceeds the cost of running a library, convert. One security fix a year across 140 services is already past it.