Indie Hacker Diaries #26: To Rewrite or Not to Rewrite

This week, I shifted my focus back to Mod.

I put it down a couple of months back—following the logic I’ve shared in my last letter—because something felt off. This week, I decided to start from scratch, but instead of doing a full-blown rewrite, I’ve been using restraint.

The reason why is that, like Joel Spolsky (of Trello and StackOverflow fame) shared over two decades ago in his infamous post Things You Should Never Do, it’s fairly well-known that rewriting an entire piece of software is risky.

It’s risky because it’s very easy to be optimistic going in, but once you start to hit headwinds, you realize the hole you’ve dug for yourself.

From his post:

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive.

I agree with this in part, but it’s written primarily from a nitpicky programmer perspective, not that of someone shipping a product from a wholistic point of view.

What I agree with is that, once you’ve decided something is done, it should be done, save for bug fixes and performance improvements. Rewriting a bunch of code just for the sake of rewriting code (for example, like Joel suggests, to improve the readability of a function to your liking) is foolish.

But rewriting code from the perspective of quality control? That’s different.

When you’re building a product, ideally, the end goal is to not just produce something that people want, but do it in a way that actually delivers on that want.

Sometimes (quite often, actually), your initial attempts at building that product might work, but they don’t really deliver the experience or value you’ve promised.

The why can be 101 different things.

The design may be clunky. The code may be slow or difficult to extend. The mental model that you started with evolved since day one and its current state no longer lines up with your current vision.

In short: you’ve learned things through the process of building. Things that, incorporated now, would make for a far better end result.

As an indie hacker, this is where you have to take off the builder hat and put on the CEO hat. Do you invest the time to incorporate your new found understanding, or, do you stick with what you have and just ship the damn thing?

Speaking personally, I’ve found that you have to get good at balancing both leveraging the new and the old simultaneously.

You certainly can write everything 100% from scratch, but it’s likely going to be at your own and your product’s expense.

Instead, it’s far better to take this approach:

1. First, figure out what doesn’t feel right and get very clear on the “why.”
2. Next, figure out what doesn’t work right. Is there some hurdle you’re constantly having to clear that’s a direct result of taking the wrong path at an earlier stage? Is there something in the code that makes writing it harder or more error-prone? Is there something on the customer experience side that’s jarring or clunky?
3. From there, evaluate what’s good in the current version. Ask what can be salvaged. What works well and doesn’t need to be changed?

Once you’ve answered those questions, shift your focus to time. Realistically (and I mean realistically, not pie-in-the-sky “of course I can do this in two weeks” optimism), how long would it take you to start over, mixing some old ideas and code with the new?

After you’ve gotten clear on those things, only then should you bet and make a move.

This week, my bet was that how I initially built Mod was overly-complex, leading me to write some really sketchy CSS that was resulting in unnecessary bugs.

I was trying to be too clever. Instead, I decided that a more verbose but clear approach to organizing the code was best. Don’t worry about reusability of classes. Don’t worry about code duplication. Just build it in a way that’s equally easy for others to consume as it is for you to build.

So, that’s what I did. I started my foundation over. I created a new repo and restructured the code for building and showcasing components to fit those needs.

Then, I started to look at what I already had.

I realized that 60-80% of what I already had written could be reused with only a few minor tweaks. The HTML and CSS I was using for most of the components was solid. The JavaScript I’d written for the interactive components was good, too.

So, instead of just blind rewriting everything, I started to adapt the old to the new. In practice, that meant copying and pasting stuff over from the previous version and then refactoring it only as much as I needed to make it align with the new structure.

The end result? I’m easily 30% of the way through the rebuild. By the end of next week? I’ll be close to done.

The takeaway from all of this is that rewrites aren’t inherently bad. Done properly, they can give you the peace of mind that your current code isn’t giving you. Done poorly, they can drag a project out and potentially put it in a state of peril.

As I frustratingly have told many of the people reading this, it comes down to thinking and discipline. You certainly can go willy nilly into rewriting things wholesale, but it’s much better to slow down and evaluate.

Once you’ve done that honestly, though, it’s perfectly acceptable to rewrite code or rebuild features. The only gotcha is that you have to accept responsibility for what that will cost you.

If you’re an indie hacker or solopreneur, that’s fairly straightforward. If you’re an employee or contractor, this advice is harder to take (and I’d argue that you shouldn’t). Anybody who’s done it knows that it’s far easier to rewrite code when you’re working alone than as part of a team.

For me, the costs of rewriting Mod as a solopreneur are far lower than the cost of it ultimately being a flop. I’m trusting that what I’ve learned in the earlier stages of development will ultimately provide a far better experience to customers later. Even if that means I have to eat crow today to get it done.