A copied service template shipped each improvement to exactly one service

Distribution by copy is where the first path broke. The template was a repository you copied, and the author says copying it was trivial while updating it was impossible: once copied, each service owned its own copy and nothing linked it back ^[9]. The population that receives version 4 is therefore the set of services created after version 4 ships ^[19]. For everything already running, the count is zero ^[19]. When the team shipped an improvement, exactly one service got it, the next new one ^[10]. A year of that left a dozen template versions in the wild with no way to tell which service was on which ^[11].

The mandate said all new services use the template, no exceptions, and adoption was immediate ^[6]. Six months in, the author looked at what the services actually contained: most had started from the template and then diverged, with an extra step here, a swapped-out base image there, a pipeline job commented out because it was slow ^[7]. "A policy gets compliance on the day it is checked and workarounds on every other day," the author wrote ^[5]. The adoption slide still said one hundred percent while paths were abandoned quietly, one service at a time ^[2].

"Nobody leaves a golden path because they enjoy maintaining their own pipeline," the author wrote ^[3]. Leaving happens at a specific moment, when staying on the path is more work than stepping off it ^[4]. On day one that moment is rare: four lines of config and you are deployed ^[12]. Day one hundred is a service with a queue consumer, a scheduled job, a second database and a customer-specific quirk, and the question then is whether the path still fits ^[12].

A strict path with no exit fails in a particular way. The first unsupported need pushes the whole service off, and the developer goes from deviating in one place to maintaining everything themselves ^[13]. What the author shipped instead was small: add a custom step, override one value, ship a raw manifest alongside the generated ones, and keep every use visible and counted ^[14]. The author expected the deploy-template hatch to be abused, and it mostly was not ^[16]. Usage clustered on three needs, all three became first-class template features, and the services using the hatch for them moved back onto the standard path without being asked ^[17]. "The hatch had not weakened the path. It had told us what to build next," the author wrote ^[18].

This is one engineer's first-person account of their own rollouts, and the post does not name an employer or give a count of services ^[21]. The upgrade failure it describes belongs to templates distributed by copy ^[9]. Where a path ships as a version reference, a base image tag or a shared pipeline library, version 4 can reach running services without anyone editing a repository, and the number to watch becomes how many services have pinned an old tag. The hatch accounting does not depend on that choice. "Counting matters more than allowing," the author wrote, and attached a threshold: ten services using the same hatch for the same reason means that reason belongs in the path ^[15].

The product framing is the part that generalises past the tooling. A path people take voluntarily has to be better than the alternative for the person using it, on the day they use it, which the author calls a product question: who is this for, what do they get, and why would they choose it over copying last month's service ^[20].