When a team is running more than a handful of services, somebody proposes a service template. It's usually framed as a convenience — stop copying the last project, start from something clean.
That framing undersells it. A service template isn't scaffolding. It's the most effective governance mechanism a platform team has, and treating it as a time-saver is how it ends up unmaintained and abandoned within a year.
A Template Encodes What You've Decided
Every service in a healthcare platform needs the same non-negotiables: structured logging with correlation, health endpoints the orchestrator understands, metrics emitted in the agreed format, tracing propagated across boundaries, authentication wired correctly, secrets read from the right place, consistent error responses, sane serialization defaults.
You can document all that. Teams will implement it inconsistently anyway — not from carelessness, but because a document is a thing you read once and a template is a thing you start from.
The difference is where the default lives. When compliance is the path of least resistance, you get compliance. When it requires reading a wiki page and remembering nine things under delivery pressure, you get nine variations.
This matters more in a regulated environment, where "every service logs access to patient data in the same auditable format" is not a nice-to-have. The template is how that becomes true by construction rather than by inspection.
The Drift Problem
Here's what kills service templates, and it kills most of them.
You generate twenty services from a template. Six months later the template has improved — a better health check, a fixed logging configuration, a security header nobody had thought of. Those twenty services have none of it. They were a copy, taken once, and they've been diverging ever since.
Now you have twenty-one versions of your standards and no way to roll anything out. The template has become a historical artefact describing what you believed when each service was born.
There's no complete solution, but there are partial ones that help a lot:
Put the substance in shared packages, not template files. The template should be thin — mostly wiring — with the actual behaviour in versioned libraries the service references. Then improving the standard is a package release, and adopting it is a version bump. A bump is something you can automate a PR for; re-copying a project layout is not.
Automate the upgrade. Dependency bots that raise PRs for your internal packages turn adoption from a project into a routine merge.
Track what's on what version. You cannot manage drift you can't see. A simple report of which services are on which version of the platform packages tells you whether the standard is real or aspirational.
Accept some drift. A template that forbids deviation gets abandoned by the first team with a legitimately different need. Make the common path easy and the exit possible.
What Belongs In, What Doesn't
In: cross-cutting concerns every service needs and no service should think about. Observability, health, auth wiring, configuration, error handling, the build and deployment pipeline, the test project layout with an integration test that proves the service starts.
That last one is underrated. A generated service that comes with a working integration test — spinning up a real dependency, hitting a real endpoint — sets the expectation that integration tests are normal here. Templates teach habits as much as they provide code.
Out: anything about the domain. The moment a template has opinions about business logic it stops fitting the next service, and teams start fighting it. Keep it to the concerns that genuinely are identical everywhere.
Also out: excessive structure. A template that generates nine projects and forty folders for a service that needs one project is imposing ceremony as a default. Most services are small. The template should produce something proportionate, and let teams grow structure when the code demands it rather than in anticipation.
It Needs an Owner
A template with no owner rots — silently, because nothing fails. It just gradually stops representing what you'd do today, and eventually someone generates a service from it and immediately rewrites half.
Owning it means keeping it current with framework versions, incorporating lessons from incidents, deleting things that turned out not to matter, and treating a generated-and-immediately-modified service as a bug report about the template.
That's a real ongoing cost. It's worth paying when you have enough services that consistency is a live problem — and it's premature when you have three, where the honest answer is to copy the last one and pay attention.
The Framing I'd Use
A service template is how an engineering organisation makes its standards the default instead of the aspiration. Judge it on whether services generated from it are consistent a year later — not on how quickly it produces the first one.
