Why "build once, reuse everywhere" rarely works
"Build once, reuse everywhere" is an attractive idea.
It promises efficiency, consistency, and scale, everything platform teams are under pressure to deliver.
In practice, it rarely works as intended.
The main issue isn't technical. It's contextual.
Different teams operate under different constraints:
Varying performance requirements
Different regulatory or market needs
Uneven maturity and delivery pressure
Different definitions of "done" and quality thresholds
A single solution that perfectly fits all contexts is rare. When teams are forced into it, they either resist or quietly work around it.
I've seen a shared authentication service built to serve "all teams." It was designed for the needs of the most regulated product line, comprehensive audit trails, complex session management, multi-factor flows.
For teams building internal tools, it was massive overkill. Integration took weeks. Simple use cases required workarounds. Teams started building their own lightweight auth rather than use the "reusable" solution.
The platform team saw resistance. The consuming teams saw bloat. Both were right.
Another problem is timing.
Reusable solutions require stability. But reuse is often pushed early, when only one or two teams have used it, when the problem is still being understood, when edge cases haven't surfaced yet.
The result is a shared solution that locks in assumptions too soon, then becomes painful to evolve because "breaking changes" affect everyone.
There's also an ownership challenge.
When something is built "for everyone," it's often owned by no one in particular. The team that built it moves on. The teams using it can't change it.
Decisions become slower, changes become riskier, and accountability blurs. Everyone depends on it. No one can fix it.
Reuse works best when it's earned, not mandated.
In my experience, effective reuse emerges when:
A problem repeats across teams in a consistent way (not just similar-looking)
The solution has stabilised through real use (not theoretical design)
There's clear ownership and support (someone accountable for consumer experience)
Teams choose it because it's better, not because they're told to
At that point, reuse becomes the natural choice, not a mandate.
The failure of "build once, reuse everywhere" isn't a failure of ambition.
It's a reminder that leverage comes from understanding variation, not ignoring it.
Reuse is an outcome, not a strategy.