Learn to Love the Rebuild

The Big Idea

Becoming a great product builder means falling in love with the process of building and rebuilding.

I have always felt like I'm somewhere between the before photo and the after photo.

As in -- I've never felt like I'm "finished" with anything, really. The next version is just around the corner. It's just mid-process.

For a long time, I assumed that feeling meant I was behind. That at some point I would arrive at a stable, finished version of myself, or my work, and finally feel settled. But the longer I build things for a living, the more I realize that the in-between feeling is a sign that I'm on the right track.

The Engineer's Reality

If you write software, you live in the messy middle whether you like it or not. You ship something that works well enough. Then you watch how it behaves in the wild. You discover the edge case you didn't anticipate, or the assumption that quietly shaped the entire architecture, or the part of the interface that makes perfect sense to you and none at all to anyone else.

And then you rebuild.

Here's the secret: for great products, that rebuild keeps happening, all the time, at every scale. You rewrite a sentence in a README because it doesn't quite communicate what you meant. You refactor a function that felt clever last week and now just feels brittle. You restructure a module. You revisit a feature that solved the wrong problem. Sometimes you rethink the product entirely. If you are unlucky or ambitious enough, you end up rethinking the company.

The rebuild is fractal. It repeats at every level. The same humility is required whether you are fixing a single line or reimagining the direction of the business.

Failing to learn from the past is a recipe for disaster

Teams that forget this are usually the ones that get surprised. Usually this is because it's taboo to question past decisions, despite the richness of learnings you get from seeing people use a product or feature after launch. Instead, boxes are checked and the product is deemed “good enough,” and instead of learning from the product's shortcomings and revisiting first principles, the team shifts into protection mode. Architecture calcifies. The roadmap becomes incremental.

Rebuilding starts to feel risky instead of necessary.

And that is exactly when the ground shifts beneath you. The cost of building something new keeps dropping. LLMs have dramatically reduced the time between idea and implementation. Patterns that once required deep specialization can now be scaffolded quickly. A small team with good taste and the willingness to rethink fundamentals can move faster than an entrenched organization that is busy defending yesterday's decisions.

Ever open up a beloved product and have the sinking feeling that it hasn't changed in years? In the past, that meant stable product-market fit. For utilitarian tools today, it might be a warning sign that someone is about to build something better.

Looking at your past work

We all cringe when we look back at what we produced years ago. I can't believe I wrote that! is a sign that you've grown. If you look at a project from two years ago and wouldn't change a thing, that is when you should worry.

The cringe is useful. It is a divining rod. It points directly at the thing that is ready to be rebuilt. Your past work is a treasure trove of opportunities for self-disruption. Take your work, make it better, and help your teammates do the same.

If you don't rebuild, someone else will

If you aren't willing to revisit your foundations, someone else will. Not because they are smarter, but often because they are less attached to the work, or to the "we've always done it this way" mentality that quietly takes hold in teams of all sizes.

Learning to love the rebuild isn't perfectionism, it's humility and honesty. Look at your own work and admit that the current version is not sacred, and you'll be able to build better things.

So look at the thing you shipped last quarter. Find the part that makes you wince. That is where you start.