Reuse: From Copy-Paste to Shared Capability

Reuse is one of those words that sounds virtuous, like “accessibility” or “tests” or “we should document things”. Everyone agrees. Nobody wants to be the person arguing against reuse.

And yet, most reuse in product teams is not a strategy. It’s a coping mechanism.

It starts innocently. Someone ships a thing under pressure. Someone else needs a similar thing. The first team says, “Just copy it. It’s basically the same.” The second team does. Everyone feels efficient. The sprint review looks great. High fives all round!

Then six months pass.

Now you have three versions of “basically the same” thing, each with slightly different behaviour, slightly different bugs, and slightly different definitions of “the standard”. Fixes don’t propagate. Security updates become treasure hunts. New people ask which version is “the real one” and everyone goes quiet for a second, because the answer is “none of them”.

This is the moment you realise that copying isn’t reuse.

It’s duplication with a head start.

This article is a practical ladder you can use to place your team’s current reuse habits. Each rung buys you something and costs you something. The goal is not “maximum reuse”. It’s reuse that holds its shape over time, so improvements flow back instead of silently forking your organisation into incompatible tribes.

Reuse Is An Agreement, Not A Technique

Every form of reuse implies a promise about change. That promise is the real mechanism.

When you copy a codebase, the promise is:
“This will not change in any way that matters.”

When you share a library, the promise is:
“This will change, but we’ll coordinate.”

When you build shared capability, the promise is:
“This will change, and you’ll get updates safely, because we’ve built the plumbing for it.”

Most reuse fails because teams skip the agreement part. They treat reuse as a technical move, then act surprised when it turns into organisational friction.

So let’s make the agreement explicit.

The Reuse Ladder

Each rung has four parts:

• What it is
• Why people do it
• The hidden cost
• How to level up

1) Copy-Based Reuse (Snippets, Templates, “Just Grab That Repo”)

What it is:
Tribal knowledge, copy/paste snippets, starter repos, and “common utils” folders that quietly become dependency landfills.

Why people do it:
It’s fast. It’s low ceremony. It works when you are optimising for this week.

Hidden cost:
Divergence. Everyone edits their local copy. The template becomes a fossil. The “shared” snippet becomes six incompatible standards. You haven’t created reuse. You’ve created a family of related rumours.

How to level up:
Decide if it’s disposable or shared. If it’s disposable, stop pretending it’s a standard. If it’s shared, give it ownership and versioning. Don’t leave it in the uncanny valley where it’s “shared” but no one is allowed to touch it.

2) Codebase Copies (The Fork-And-Pray Model)

What it is:
Clone an entire service/app, tweak it, ship it. It’s technically independent, which feels like freedom until you remember what maintenance is.

Why people do it:
Deadlines. Fewer meetings. No need to negotiate with the original team. You can move.

Hidden cost:
You’ve broken the improvement engine. Fixes and enhancements don’t flow back. Security updates become manual labour. Two products drift apart, then later you pay to “standardise” them again, which is the same work twice with extra resentment.

This is how organisations quietly manufacture inconsistency.

A common version: a permissions module gets copied into two products. One product tightens access rules after an audit. The other doesn’t. A year later you discover that “we already solved this” only meant “we solved it somewhere else”.

How to level up:
Extract the shared part into a library/service, or build one thing properly multi-tenant. If you can’t, at least be honest and label the copies as copies, then plan for how critical fixes will propagate without heroics.

At this point, organisations tend to have a choice: keep scaling through duplication, or start investing in shared assets that improve over time.

That next rung is where reuse stops being “a clever shortcut” and starts behaving like something you can rely on.

3) Shared Core Project

What it is:
One core project used by multiple teams. Improvements flow back. Everyone benefits from fixes.

Why people do it:
Because someone finally did the maths and realised the copy model scales badly.

Hidden cost:
This is where reuse stops being “just code” and becomes product work.

You now need:

• a release process
• backwards compatibility
• a changelog people actually read
• a way to say “no”
• a way to accept contributions without turning them into a second job

Also, someone has to own it. Ownership is not “a channel in Teams”.

How to level up:
Treat the core as a product. It has users. It has support needs. It needs constraints, a roadmap, and a contribution path that is easier than building a parallel thing in secret.

Once you have a shared core, the next question is surprisingly political: what exactly are we sharing?

If the answer is “everything”, you’ll end up with a shared dependency that blocks everyone. If the answer is “nothing”, you’ll drift back into forks. The work is drawing boundaries that let teams move without breaking each other.

4) Stable Boundaries (Contracts Over Clones)

What it is:
Clear interfaces. Extension points. Feature flags. Plug-in patterns. You standardise the contract, not every detail.

Why people do it:
Because forcing identical behaviour across products is often the wrong goal. You want shared capability with local freedom.

Hidden cost:
Upfront design and discipline. Boundaries take effort to define. People will try to bypass them, because bypassing boundaries is faster than respecting them.

How to level up:
Make the boundary the easiest path. Document it with examples. Test it. Instrument it. If teams keep bypassing it, the boundary is either too painful or too vague. Fix that rather than writing a stern wiki page.

This is also where UI reuse gets interesting, because teams often think they’re reusing components when they’re actually trying to reuse decisions.

A design system isn’t a catalogue. It’s a way of making the same choices on purpose.

5) Component Libraries And Design Systems

What it is:
Reusable UI primitives and patterns: tokens, components, accessibility rules, content patterns. Improvements flow to all products when done properly.

Why people do it:
Consistency, speed, fewer UX regressions, easier onboarding. Also, it stops every team inventing their own button philosophy.

Hidden cost:
Design system theatre. The library exists, but adoption is optional, contributions are hard, and the components don’t match real product needs. Teams fork components “temporarily” and you never see them again.

Here’s the boring, real-world version: one team forks the button because they “just need a quick variant” for a campaign. In the fork, the focus state disappears. Nobody notices until a keyboard user does, or until someone audits. The design system still looks perfect. The product is the one that’s drifting.

How to level up:
Build with product teams, not for them. Track adoption. Make contribution paths realistic. If it takes three weeks and a council to change a component, teams will route around you. They are not evil. They are busy.

6) AI Code Rules (Organisational Taste In Machine-Readable Form)

What it is:
Repo conventions, lint rules, scaffolding, templates, Cursor rules, “this is how we do X here”, with examples the AI can follow reliably.

Why people do it:
Because AI makes output cheap. Consistency becomes the scarce resource. Rules reduce review burden and stop every PR becoming a debate about structure and style.

Hidden cost:
Rules rot. People cargo-cult. The AI follows the rules while missing the intent. You get consistency of surface, not consistency of outcomes.

How to level up:
Treat rules like policy. Give them owners. Add examples. Add tests where you can. If a rule is important, it should be enforceable. If it’s not enforceable, it should at least be explicit, with a “why”.

And that brings us to the final rung: the bit most reuse conversations never quite reach.

Because once output is easy, the limiting factor isn’t writing the code. It’s making the same good decisions repeatedly.

7) Decision Logs (Reusable Judgement)

What it is:
A short record of what you decided, why you decided it, what you traded off, and how you’ll know you were wrong.

Why people do it:
Because the hardest part of building is not typing the code. It’s making good decisions consistently across time, teams, and toolchains.

Decision logs let humans and AI act as if they were present when the decision was made.

Hidden cost:
It exposes disagreement and ambiguity. Which is uncomfortable. Also, it requires discipline.

How to level up:
Make decision logs part of the flow. If it lives in a folder nobody opens, it’s a shrine. If it’s baked into PR templates, architecture reviews, incident write-ups, and product decisions, it becomes organisational memory.

Where Reuse Fails (And Why It’s Predictable)

Reuse efforts rarely fail because people are incompetent. They fail because the organisation doesn’t pay for the boring parts.

Here are the usual failure modes:

• No ownership: shared thing becomes abandoned thing.
• No contract: consumers depend on internals, everything becomes a breaking change.
• No release discipline: updates become scary, so nothing improves.
• No incentives: teams build parallel versions instead of contributing upstream.
• No retirement plan: you keep “reusing” something past its sell-by date because nobody is allowed to delete it.

If any of this sounds familiar, congratulations. You’re normal.

The question is whether you want reuse to be a source of drift or a source of stability.

AI Changes The Maths

AI didn’t change what good reuse is. It changed the failure mode.

In the old world, code was expensive. Copying looked efficient because it reduced immediate effort.

In the current world, output is cheap. AI can generate ten plausible implementations before you’ve finished your coffee. That’s useful. It also means you can accidentally create ten slightly different “standards”, all clean, confident, and quietly incompatible.

The new cost is alignment.

A choice is “let’s go with option B.”
A decision is “we’re choosing B because of X, we accept Y, and we’ll know we were wrong if Z happens.”

Without that, AI doesn’t just accelerate delivery. It accelerates drift. You get systems that look consistent in PRs and screenshots, but behave differently under pressure. The exact opposite of what reuse is meant to buy you.

So yes, you still want code rules, conventions, and scaffolding. But the real lever is preserving the reasoning that makes those rules make sense.

If you want the longer version of that argument, I’ve unpacked it in my article on curation.

That’s why the top rung matters. Because the most reusable asset in an AI-heavy workflow isn’t the code.

It’s the judgement.

A Decision Log Template You Can Actually Use

Keep it short. The point is not to capture every thought. It’s to preserve the reasoning that future people, and future models, will need.

Decision: <short name>
Context: What problem were we solving?
Decision: What did we choose?
Why: The reasons that mattered most.
Trade-offs: What we knowingly gave up.
Rejected options: What we didn’t do and why.
Guardrails: What must remain true (constraints).
Evidence: Links, incidents, research, data.
Review trigger: What would make us revisit this, and when?

If you want to make it AI-friendly, add one more field:

AI prompt stub:
“When generating code in this repo, assume: <3–5 bullet summary of the decision>.”

That’s it. You’re not writing a novel. You’re preventing re-litigating.

How To Level Up Without Turning It Into A Programme

You don’t need a reuse transformation initiative. Please don’t create one. That’s how you get slides about “synergy” and a library nobody adopts.

Instead:

1. Pick one thing that has already been copied twice.
   Not the perfect candidate. The real candidate.
2. Name the users.
   Which teams/products depend on it? Who will benefit from updates?
3. Choose the right rung.
   Does it need to be shared code? A service? A component? A documented pattern? A decision log?
4. Assign an owner.
   A named person or team with time allocated. “Everyone” is an abdication.
5. Define the contract.
   API, props, tokens, policy, template, whatever fits. Make the boundary explicit.
6. Create a release rhythm.
   Even monthly is fine. Predictability beats heroics.
7. Make contributing upstream easier than forking.
   If contribution feels like bureaucracy, people will fork and you will deserve it.
8. Start logging the decisions that keep coming back.
   If you have the same debate every quarter, that’s not a debate. That’s missing memory.

The Real Point

The goal is not maximum reuse. Maximum reuse is how you end up with a single shared component that blocks ten teams because nobody can agree on a border radius.

The goal is reuse that stays true over time.

The early forms of reuse save effort once. The mature forms create compounding benefits. The final form preserves judgement, so your organisation can move fast without constantly forgetting why it chose what it chose.

Copying is how folklore spreads. Shared capability is how learning spreads.

If your “best practice” requires heroic memory to survive, it’s not a best practice.

It’s folklore.