My friends at other companies tell me the same thing keeps happening. The closest existing tool doesn’t quite fit somebody’s case, or it belongs to a team they don’t know how to reach. They ship their own version instead. A few weeks later, the team has several near-duplicates and no canonical one.

My own org isn’t an exception. The categories shift, the dynamic doesn’t.

Engineers want to solve their own problems, and AI made acting on that motivation cheaper than ever. What’s changed is timing.

Shared pain used to mean somebody collected feedback, the team chose a direction, and one tool got built. Now shared pain means several engineers ship parallel solutions, and the team works out which one should win afterward. Or the engineers never have that conversation, and the duplicates just stay.

Pre-AI, scaffolding a usable internal tool was a multi-day task. Now the first commit lands in an afternoon. That’s why the conversation moved.

None of the engineers I’ve talked to set out to build a duplicate. Each had a defensible reason to start their own. An ownership boundary, a hard deadline, an existing tool that didn’t quite fit their case.

Each one was solving a real problem. The duplicates show up when individual speed outruns team consolidation.

By the time anyone notices, three more have started.

#Downstream alignment is harder

Upstream alignment is cheap because it’s about hypotheticals. Shape, users, and features can be argued on whiteboards. You can change your mind cheaply, because nothing exists yet.

Downstream alignment is about real artifacts. Three engineers have shipped working code, written docs, and acquired some number of users. Each tool has features the others don’t.

Asking the engineers to retire what they built is asking them to discard sunk cost. That’s their time and their work, sometimes their promotion case. The decision has weight that upstream decisions never carry.

Most engineers I know would rather have the upstream conversation. It’s faster, and the work is hypothetical. The downstream version requires somebody to absorb the loss of the not-chosen tools, and “somebody” is usually the engineers who built them, none of whom want to volunteer. The default outcome is no consolidation, and the duplicates stay.

#The build is the cheap part

The cost of a tool is mostly what comes after the build. Maintenance, support, and on-call multiply with each duplicate instead of pooling. Each engineer who built one becomes the only person who can fix it.

They didn’t sign up to be in the critical path for their tool, but they are now. The only one who can debug the upstream API change. The only one who knows why the on-call paging rule fires. The first vacation reveals the dependency.

Each tool is locally rational. Together they’re a tax. The tax is the price of doing alignment downstream instead of upstream. When the alignment never happens, the tax is forever.

#After the prototype

Building is the right move at the prototype stage. Four overlapping prototypes is fine while nobody knows yet whether the problem is real. Four overlapping prototypes a year later, each owned by the engineer who started it, is when alignment has to happen.

The skill is recognizing that moment and acting on it. Pick one of the four, usually not yours. Move the unique features back to the canonical tool, write the missing docs, and retire the rest.

The output is everyone’s project folders becoming one.

#What time will tell

That’s what I can do at the individual level. The right shape of the work at team and org scale isn’t settled yet. As with any abstraction shift, only time will tell how we resolve this.

Building was never just about building, the same way the work was never just the work.