“Why can’t we just reuse …”
Point 8 of the Technology Code of Practice asks anyone spending public money on technology to show they've considered whether they can share and reuse what already exists. It's a sensible ask, and a mandatory one if you're going through spend controls.
Duplicated effort is real, and it's expensive.
But "reuse" is one word covering at least six quite different arrangements, and the policy that asks the question doesn't specify which one you're agreeing to. That gap is where the cost hides.
It's a question I've heard in some form at every organisation I've worked in, but it comes up more often, and more urgently, during periods of real change. Budgets tighten, structures shift, and someone reasonably asks why three teams are building three versions of something that looks, from a distance, like the same thing.
It's a good question. We rarely answer it properly, and that failure costs us more than the duplication we set out to avoid.
Definition
Here are six arrangements that single word is doing the work of, and the person asking rarely specifies (or knows they need to specify) which one they mean:
Copy HOW we built it, and build your own.
Take a copy of our code and run your own version.
Take a copy, but send changes back to us.
Consume our published, versioned components and build your own thing.
Plug into our running service directly.
Have our team build your version too.
Each of those is a different commitment. They carry different costs, different ownership models, and different consequences if they go wrong.
Nodding along to "let's reuse that" without agreeing which one you mean (and people almost never say which) is how a sensible instinct turns into an unplanned liability eighteen months later.
Reuse subtypes mapped to complexity in the short and long term.
There's a second axis worth naming too, and I'm grateful to Isobel Croot and James Darling, whose 2022 talk on public-sector reuse sharpened the points that follow.
As well as how you reuse something, there's the question of what layer you're pointing at. Reusing a whole running service is a different proposition from lifting out a single code component, which is different again from adopting a shared platform, or just borrowing a pattern. The nested picture below is one way to see it: a component sits inside a product, which sits inside a service, and any of those layers, plus a standalone platform or a documented pattern, can be the thing you reuse.
One thing this exposes early: working in the open is not the same as reusable code. Publishing your source gives you transparency, security, and shared learning, all genuinely worth having. It does not, on its own, make the code something another team can pick up and run. Reusability is extra, deliberate work on top of openness: documentation, versioning, a stable interface, a maintainer. Plenty of "we open-sourced it" is quietly assumed to mean "others can reuse it," and the gap between those two is where disappointment lives.
The trap is the shape of the cost, not the size of it
Here's the pattern I keep seeing. Copying something and running it independently is nearly free on day one. Someone points at a repo, clones it, and gets on with their work. Building or joining a properly shared service is expensive on day one: multi-tenancy, onboarding, support rotas, a roadmap that has to serve more than one master.
Slow down, curve ahead
Those two cost curves run in opposite directions. The cheap option gets expensive slowly and invisibly, because every copy needs its own patching, upgrades and assurance (forever, and usually by someone who didn't choose to take it on). The expensive option gets cheaper per additional user once the initial investment is made.
The trap is arguing for the second while budgeting for the first.
Somebody imagines the economics of a shared platform while actually committing the effort of a quick copy-paste. That gap doesn't disappear. It turns up later as an unfunded team quietly propping up something three other teams now depend on (something that was never resourced as the product it has become).
What gets missed in the room
In any reasonably regulated or complex organisation, and especially in the public sector at the moment, a few things routinely get left out of the reuse conversation entirely:
Assurance and compliance.Something signed off for one context isn't automatically safe or compliant in another. A change in audience, data or use case can trigger a full reassessment (a cost almost never in the original estimate).
Funding.Most budgets are structured around individual programmes. There's often no natural mechanism for funding something that now serves three of them. Sorting that out after the second team already depends on it is a negotiation conducted from weakness, usually by whoever has been quietly carrying the cost.
Contracts. Delivery work that runs through suppliers is engaged against a specific, scoped statement of work. That scope doesn't stretch just because stretching it would be convenient. Extending it is a commercial conversation (not a technical one) and it needs to happen early.
Governance. Data protection and information governance obligations tend to apply per use case, not per codebase. A new consumer is usually a new assessment, however much of the underlying code is shared.
There's also a failure mode specific to shared things, which Messrs Croot and Darling memorably call death by a thousand customisation options:
To serve everyone, a shared service or library starts absorbing configuration: a flag here, an exception there, an override for the one team whose case doesn't quite fit. Do that enough times and you have something nobody can maintain and that serves no one well. Reusable doesn't mean infinitely flexible. Sometimes the honest answer is that two needs are different enough to stay separate.
A test that's cheap to run
The most useful discipline I've found is absurdly simple. Before agreeing to any form of reuse, answer three questions honestly:
1. Who owns it? Which named team or role controls the roadmap and accepts changes?
2. Who pays for it? Which budget covers ongoing maintenance and support, and how do new consumers contribute?
3. Who's liable when it breaks? Who gets the call at 2am, and what have consumers actually been promised?
If a proposal can't answer all three, it isn't a reuse strategy yet. It's a hope that someone else will absorb the cost. That's not a reason to say no. It's a reason to go and find the answers before you say yes.
And to be clear about what this is: it isn't a formula that spits out the right reuse type.
The right answer depends on things no framework can see from the outside, the specific teams, the state of their funding, the supplier position, the appetite for risk. What the questions do is make the choice legible. They turn "why can't we just reuse that" into a short, structured conversation, and they give whoever owns the decision something concrete to take upward: here's the type of reuse we're proposing, here's what it will cost, here's who needs to carry it. The value isn't in being told what to do. It's in making the tradeoff visible to the people who are actually signing up for it.
Drift is a decision, even when nobody makes it
The place this matters most is where two copies of something start life identical and slowly stop being identical. Once you've taken a copy, there are only three honest positions to hold:
- Stay aligned. Merge from the original on a schedule, funded and staffed. Expensive, but you keep one family of code you can reason about and assure as a whole.
- Diverge deliberately. Declare the copy a separate product with its own owner, backlog and assurance. You accept the duplication knowingly, and you plan for it.
- Diverge for now, converge later. Split for speed, with an actual date and a funded plan to come back together (or to formally give up and split for good).
What I want to be clear about is this: choosing none of the three doesn't mean nothing has been chosen.
It means you've picked the second one by accident, without the ownership that makes it work. The copies diverge anyway. The only difference is that nobody is accountable for either of them, and nobody decided that should be the case.
When you have this conversation matters as much as how
There's a timing problem underneath all of this.
We often decide something is reusable before it exists. A business case promises a "shared platform," reuse is written into the mandate, and three teams are told to build on it, all before anyone has learned whether the thing is actually worth sharing.
That's backwards. Most things that genuinely deserve to be shared earn that status by being used, in one real context, long enough to prove they're stable and that the need generalises. Mandating reuse up front skips the part where the thing matures. You end up committing everyone to a shared dependency that hasn't yet demonstrated it can bear the weight, and unpicking that later is far more expensive than never having mandated it.
Think of like this: Reuse is usually something you recognise, not something you decree.
The useful move early on isn't to mandate sharing. It's to build the first thing well, in the open, with clean enough boundaries that it could be shared later, and then to have the deliberate conversation, name the type, ask the three questions, when a second real consumer actually turns up.
Designed to be shareable is a gift to your future self. Mandated to be shared before it's proven is a bill you'll pay later.
Why I'm writing this now
None of this is really about technology. It's about being honest with each other, early, about what we're actually agreeing to.
The policy is right. Sharing and reusing what we've already built is the correct instinct, and the Technology Code of Practice is right to ask the question. The missing piece is the conversation about which kind of reuse we mean, and who carries it once we've said yes.
In periods of significant organisational change, the pressure to reuse rises at exactly the moment when the structures around us (funding models, contracts, governance) are least settled. That's precisely when a shared vocabulary matters most. Getting it wrong doesn't just cost money. It quietly erodes trust between teams who were trying to do the sensible thing.
I'd rather we got ahead of that than cleaned up after it. If you've navigated this well, or badly, in your own organisation, I'd genuinely like to hear how. It's the kind of problem that gets easier the more people compare notes on it openly.
