Copying Is Cheap. Running the Copy Is Expensive

Behind every loud "we built it ourselves" hides a simple truth far too often: we didn't invent — we reworked. And we don't pay for it on release day, we pay for years, at every stage of maintenance.

Three phrases that sound proud

For the past couple of years I keep hearing the same lines:

• "We built our own Kafka analog."
• "We localized GPT."
• "We stood up CI/CD with no imported software."

Each phrase sounds like a victory. A report to the top, a checkbox on the roadmap, a happy client. And each time — with a faint aftertaste of déjà vu. Because "we built it ourselves" usually means not "invented from scratch" but "took something ready-made and swapped the nameplate." We assembled our thing on top of someone else's foundation — and logged it as an achievement.

I'm not moralizing. I've picked compatibility over invention plenty of times myself — because of the deadline, because the team knows this stack, because "if it works, don't touch it." The problem isn't that we copy. Copying is a normal engineering move; the whole industry runs on reuse. The problem is that we've stopped noticing the difference between "we reused" and "we created" — and we celebrate the second when we honestly did the first.

A gallery with no living faces

What pushed me to write this was a single memory. At Bauman Moscow State Technical University, where I studied, there was a hallway — a gallery of portraits of great engineers and inventors. You walk down it and see the faces of people who created, discovered, dreamed up things that didn't exist before them.

And then an uneasy thought catches you: not one of them is alive. All of them are from the past. As if a crack had opened between the generations that created and the generation that substitutes. Not a technological crack — a crack in meaning. We hold tools more powerful than any of them ever had. And yet we ask ourselves less and less often: "what, exactly, did I invent here?"

We no longer invent — we adapt. We take someone else's architecture, wedge it into our own perimeter, and then drag a Frankenstein system around for years: no coherent documentation, no ecosystem around it, without the hardware and resources the original was designed for in the first place. Technically the task is closed — the box is standing, the lights are on. Economically, that's exactly when the slow leak begins: money, time, and the support team's nerves.

You're not paying for the copy — you're paying to run it

Here's the core thesis this whole thing was written for. Copying a solution is cheap. You build it once, deploy it, file your report. Running the copy is expensive, and the invoice arrives later.

In practice it looks mundane. Upstream ships a new version with a critical fix — and you can't just update, because your build diverged from the original long ago and now hangs on a dozen local patches nobody remembers the reason for. The original grows a set of ready-made integrations and connectors — and you don't have them, because the ecosystem doesn't come in the box; you have to build it yourself. You hire someone — and discover that their knowledge of the "real" product only helps in part: your fork behaves differently, and half the time the new hire isn't learning the technology, they're learning your unique set of rakes to step on.

Every project like this is a Frankenstein assembled from spare parts: it works right up until you start asking awkward questions. Ask "so how do we upgrade to the next major?" — and the seams start splitting open.

The problem runs deeper than "we copied something." Along with the code, we inherited someone else's logic — their trade-offs, their assumptions about load, about scale, about what hardware is on hand. And now we pay for those decisions every day of maintenance, even though we weren't the ones who made them.

Compatibility is not innovation

Let's call things by their real names, honestly. Compatibility is not innovation. It's a way to reduce the risk of getting it wrong. A perfectly valid strategy when the goal is to plug a hole fast and not retrain the team. But you can't pass it off as a technological breakthrough, because by its very nature it's conservative: you're repeating what someone already came up with, and at best you're catching up.

That's where the three familiar genres come from: "copies without support," "analogs without the performance," and "clones without the product's philosophy." A clone reproduces the form but doesn't inherit the meaning — the reason the original was built exactly the way it was in the first place. You get the outer shell of the solution, but you don't see which forks in the road led the authors to those trade-offs. And without that, every non-standard situation turns into guesswork.

This is felt especially sharply in AI. In a world where even OpenAI is rewriting its own architecture for the sake of energy efficiency — meaning the players at the frontier keep inventing — we routinely clone transformers on whatever hardware we managed to get hold of and call it import substitution. Reproducing someone else's model is engineering work in itself, no argument there. But reproducing is not the same as rethinking. And if you copy someone's architecture wholesale, you automatically inherit its limits too: its appetite for resources, its ceiling on efficiency, its notion of what's even possible.

Sovereignty isn't for sale on a Marketplace

And here's the question I want to leave with the leaders and the "creators": what is our priority right now — compatibility at any cost, or rethinking our own architecture?

Both answers have a right to exist. If the task is to stop the leak here and now, compatibility is the more honest and cheaper choice. But if we're seriously talking about technological sovereignty, then it can't be bought ready-made on a Marketplace and it can't be assembled from someone else's spare parts. Sovereignty is the ability to design your own thing for your own constraints: for your hardware, your data, your requirements. And that's no longer about "downloaded and adapted," it's about the mindset of engineers who aren't afraid to break the familiar and start from a blank page where that's justified.

There's no need to swing to the other extreme and rewrite everything on principle — that's the same trap, just more expensive. This is about being honest with ourselves: where do we reasonably reuse, and where do we hide plain copying behind the word "import substitution" because it's more comfortable to report that way. The difference between "we adapted" and "we created" isn't cosmetic. It decides whether you'll stay the eternal follower or, at some point, start setting the direction yourself.

Fellow engineers, fellow IT people — it's long past time we stopped being a mirror that reflects someone else's light and became a source of it again. At least sometimes. At least on one project, where you can afford to ask not "what could I replace this with," but "how would I build this if I were building it for the first time."

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP