Not-Invented-Here: Why You Keep Rebuilding Things That Already Exist

What it actually looks like

You opened the documentation for a tool that does the thing you need. Within twenty minutes you had found something you did not like — the API shape, a dependency you would not have chosen, an abstraction that assumes a use case you do not have. You closed the tab. Four days later you are still writing your version.

Your codebase contains your own implementations of at least three problems that have well-maintained solutions. Authentication. A job queue. A date-handling layer. Each one has a story about why the existing option was wrong for you, and each story is true, and you have never added up the weeks.

When someone asks what you have been working on, the honest answer for the last fortnight has been infrastructure nobody will ever see. You describe it slightly quickly.

You can name the specific flaw in every major tool in your stack's category. You have not shipped the feature those tools were going to unblock.

There is a phrase you use, and it sounds like diligence: I want to understand it properly. You have said it about a payment integration, a deployment pipeline, and a text editor plugin. It has never once been followed by a decision to adopt.

And there is the feeling itself, which is the clearest signal in the list. Choosing a library feels like settling. Writing it yourself feels like the real work starting.

Who this happens to

This is common among engineers with genuinely good taste.

If you have opinions about how software should be built, you developed them by noticing when things were done badly — and once that noticing is sharp, every third-party tool you open will offer you something to notice within a few minutes. The taste is real and it is an asset. It also means the evidence for rejecting any given option is always available, on demand, in under half an hour.

It is common in founders who enjoy building more than shipping. Nobody says this out loud, because it sounds unserious, and it is not. The building is the part you are good at and the part where the standards are yours to set. Adopting someone else's tool skips the good part and moves you straight to the part you like less: integrating, configuring, and then facing the customer-facing work with nothing left to hide behind.

It happens to people who have been burned by a dependency. If you have lived through a vendor's breaking change, a library going unmaintained, or an outage you could not fix because the code was not yours, you learned a real lesson about control. The lesson is correct. It is also being applied at a scale it was not learned at.

And it happens to solo and very small teams most of all, because there is no one whose week is being spent. On a team of thirty, rebuilding a queue is a visible decision that someone questions. Alone, it is Tuesday.

What sets it off

Look at what you were about to do when the rebuild started.

The most common trigger is the evaluation itself. You sit down to choose a tool, which is a genuinely uncomfortable task — it involves reading someone else's decisions, accepting constraints you did not pick, and committing before you have full information. Building your own removes all three discomforts at once, and it does it while looking like more rigour rather than less.

A minor flaw sets it off reliably, and the size of the flaw does not matter. The tool does ninety percent of what you need and the missing ten percent is annoying. In almost any other decision you would call that a good trade. Here the ten percent becomes the whole conversation.

The urge to understand it fully is its own trigger, and a seductive one, because learning is unambiguously good. But notice when it arrives: not when you have time, but when the alternative is a task with an external judge. Understanding the internals of an authentication flow is a defensible way to spend Thursday. Shipping the onboarding it was blocking is not defensible in the same way — it can simply fail.

And it fires hardest right after something outside your control went wrong. A provider had an incident, a package published a breaking version, an upgrade cost you a day. The pull toward owning everything is strongest in the week after being let down by something you did not own.

Why it keeps happening

The mechanism is that the cost is invisible and the reward is immediate.

Rebuilding a solved problem pays every single day. The tests pass, the implementation gets cleaner, you understand the domain more deeply than you did yesterday, and it is all your work, done to your standard. That is a real reward and you have earned it. Adopting the library pays nothing on the day — you read documentation, you fight a configuration file, and you end up with a system you understand less well than you did this morning.

Meanwhile the cost never presents a bill. Nobody sends you an invoice for the three weeks. There is no moment where a queue implementation announces that it has consumed a fifth of your runway. The expense is entirely made of time that felt productive at the time, which is the hardest kind to notice and the only kind you cannot get back.

And the justification is genuinely good, which is what makes this so durable. You will understand it better — that is true. You will control it — also true. It will fit your case exactly — true again. Every individual argument survives scrutiny. What does not survive scrutiny is the total: a founder with limited months who has spent a meaningful fraction of them building things that were already available, in service of a product whose actual differentiator got none of that attention.

There is one more thing worth naming plainly. Under the craft argument there is often a quieter one about proof — that being the kind of engineer who could build it matters, and that using the ready-made version leaves that unproven. But the proof was never in the queue. It is in what you choose to point the skill at.

What actually helps

Make one question mandatory before any non-core build: is this the thing only I can do, or is this a solved problem? Ask it out loud, before you open the editor, not after. It takes ten seconds and it is remarkably hard to answer dishonestly when you can hear yourself.

Give the evaluation a timebox and a bar, and set both before you start. Twenty minutes, and the bar is eighty percent — if an existing tool covers eighty percent of what you need, you adopt it and work around the rest. Written down in advance, that bar survives contact with the flaw you are about to find. Decided in the moment, it never does.

Write the cost on the same page as the decision. Before you start building, put down your honest estimate of the weeks, and beside it the one customer-facing thing that will not happen in those weeks. Not as discipline — as information. Sometimes the trade is right, and you will only know which case you are in when both halves are visible at once.

Take the flaw seriously and separately. If the missing ten percent genuinely matters, the answer is usually a thin layer you write on top of the tool, not a replacement for the tool. That is a day of work rather than a month, and it keeps every improvement other people make to the part you did not write.

And point the craft at the part that is actually yours. You have real skill and a limited number of months to aim it at something. There is exactly one piece of your product that nobody else can build, because it comes from what you understand about this problem that they do not. Every week spent on commodity infrastructure is a week that piece did not get. Adopting the library is not a concession about what you could do. It is a decision about where your work is worth the most.