I Kept Rebuilding Things That Already Existed

I have lost an astonishing amount of time on this project building things that already existed. Careful, polished, lovingly-crafted reimplementations of tools and infrastructure that the world already had — working, tested, and free for the taking. Each one felt completely justified in the moment I started it. Taken together, they add up to one of the largest and most avoidable wastes of the whole effort.

This is an uncomfortable thing to admit, because every single instance came with a reason that sounded, at the time, like sound engineering judgment. It took me a long while to notice that the reasons were almost always rationalizations for something I did not want to look at directly.

The reasons always sound good

The case for building it yourself is never hard to make. Mine will fit my specific needs better than a general-purpose tool. I will understand it completely, down to every line, instead of trusting a black box. The existing option has flaws and annoyances I can avoid. I do not want to take on the dependency, the version churn, the someone-else’s-decisions of it.

Every one of those arguments is occasionally, genuinely true. That is exactly what makes them so dangerous. Because most of the time, they are not the real reason at all — they are respectable-sounding cover for a motive that has nothing to do with what is best for the project.

Building is more fun than integrating

Here is the honest thing underneath, the one I did not want to say out loud. Building something new is creative and satisfying. It is the fun part, the part that feels like real engineering, the part where you get to make decisions and watch something take shape from nothing. Integrating someone else’s tool, by contrast, is fiddly and frustrating and faintly humiliating — reading unfamiliar documentation, working around design choices you would not have made, debugging an interaction you do not fully understand.

So I would reach for “I will just build it myself” not because it was the correct call, but because it was the more pleasant one. And then, crucially, I would dress that preference up in the language of engineering judgment, presenting a decision driven by what I wanted to do as though it were driven by what the project needed. The rationalizations were sincere. They were also, mostly, a costume.

The cost was the problem that was actually mine

The real price was not even the weeks I poured into each reinvention, as bad as that was. It was what those weeks were stolen from. Every stretch I spent rebuilding a solved problem was a stretch I did not spend on the one problem that was genuinely unsolved and genuinely mine — the thing no existing tool could do for me, the specific hard question that was the entire reason the project existed in the first place.

That was the thing only I was going to work on. The world had already solved the generic infrastructure; nobody but me was going to solve my actual problem. And there I was, spending my scarcest and most valuable resource — my limited supply of focused attention — on precisely the parts that needed it least, while the part that needed all of it waited. I had it exactly inverted.

Reinvention is a tax you pay forever

What I also underestimated is that building your own version is not a one-time cost. It is a permanent liability. The homemade tool is now yours to maintain, debug, extend, and document, forever, alone. There is no community finding and fixing its bugs. There is no documentation except the documentation you write. There is no one to ask when it breaks in a way you do not understand, because the only expert in the world is you, and you have forgotten how it works.

The existing tool I had spurned was maintained by many people, hardened by countless other users hitting its edges before I ever would. My replacement was maintained by exactly one tired person who had many other things to do. That asymmetry does not show up on the day you build it. It shows up every day after, quietly, as a tax on everything else, and it compounds.

When building it yourself actually is right

In fairness, I do not want to overcorrect into “never build anything.” Sometimes building it yourself is genuinely the right call. When the thing in question is your core problem, the actual hard part, then of course you build it — that is the work. When no adequate option exists. When the existing options are truly, specifically wrong for a reason you can articulate concretely and defend.

That last point became my test, and it is a useful one. Before building a replacement for something that already exists, I now force myself to state, specifically and out loud, exactly why every existing option fails for my actual need. Not “I would prefer mine.” Not “theirs is annoying.” A concrete, defensible reason. If I cannot produce one — and far more often than I would like, I cannot — then I am not making an engineering decision. I am rationalizing the more fun choice, and I should go be bored and use the thing that already works.

Spend your originality where it is required

The reframe that helped most was to think of original effort as a strictly limited budget. You have only so much capacity for deep, novel, from-scratch work, and every unit of it you spend on a problem the world has already solved is a unit stolen directly from the problem only you can solve. Originality is precious precisely because it is scarce, and spending it on solved problems is the most expensive kind of waste, because of what it displaces.

So the discipline, counterintuitively, is to be as boring and conventional as you possibly can almost everywhere — to borrow, reuse, accept the imperfect-but-working tool, swallow the annoyance of someone else’s design — specifically so that you can afford to be genuinely original in the one place where originality is actually the job. Be relentlessly unoriginal about the vehicle so you have something left for the destination.

The deeper lesson: the goal is the destination, not the vehicle

What it all came down to was a confusion I had not noticed I was making: I had quietly equated building things with making progress. They are not the same. The tools are the vehicle. They were never the destination. Nobody was ever going to reward me for a beautiful, hand-crafted version of a thing that already existed in a dozen forms — and certainly the market, the actual judge, did not care in the slightest how elegant my reimplemented plumbing was.

The only thing that ever counted was distance traveled toward the real goal. And reinvention, I came to understand, is one of the most scenic and satisfying ways there is to stand perfectly still — to feel productive, to produce real artifacts, to work hard, and to arrive precisely nowhere. The work I was avoiding by building was the only work that was ever actually mine to do.

— No signals, no returns, not investment advice.