The Case Against Starting Over

There’s a particular kind of optimism that comes with starting over. A blank repository has no odd decisions left behind by someone else and no file nobody wants to open. We feel the pull of it too.

Here are three times we changed something fundamental in software people were already using. None of them started over.

Easy Screenshot Plus

Easy Screenshot Plus began as somebody else’s code. We were using Easy Screenshot, an open-source Firefox extension whose original project had gone inactive, so we forked it to keep it maintained. That meant learning the codebase, and once we were in, we kept going, adding configurable toolbar actions and custom keyboard shortcuts.

Editable annotations were harder, because they ran into an early decision in the original: every shape was drawn straight into the screenshot’s pixels. Once a box was drawn, it was just pixels, and there was nothing left to select or move.

That’s usually the moment a rewrite starts to sound sensible: the foundation doesn’t support the feature you want, so why not replace the foundation? But what stood in the way was one assumption about how shapes were stored. The size of the solution should be proportional to the size of the problem. We moved annotations onto a layer of their own, above the image, which is what made selecting and moving them possible, and we kept the quick, in-browser workflow that made the extension worth using in the first place.

Burn After

Burn After launched on Product Hunt and finished in the top 10 products of the day. The feedback turned out to be worth more than the placement, and it kept coming back to trust. For an app that exists to carry sensitive files, that’s about as close to the core as feedback gets.

So we moved encryption into the browser, with people already using the product. Files are now encrypted before they’re uploaded and decrypted in the recipient’s browser, and the service never holds the key. What people were already relying on carried on: a link that works once, and a file that gets deleted afterward.

Most work on existing software looks like that: an important, structural change to something people already depend on. Starting Burn After again from scratch would have reopened every part of it to change one.

This site

When we redesigned this site, almost everything you can see changed: the home page, the header and footer, the portfolio, the blog, and the pages for our apps. We did it inside the same Astro project, one piece at a time. The new home page went in first, then the new header and footer went onto every page, including the ones still using the old template. The remaining pages moved over a section at a time, and the old page layout was the last thing we deleted.

Working in place meant the old code was still there to read as we replaced it, including the parts nobody looks at. The old site remembered whether you’d picked light or dark mode, in your browser, under a key called theme. The new theme switch reads the same key and the same two values, so a pick made before the redesign still holds after it. Starting fresh, it would have been easy to give the new switch its own key and never notice the difference. Nobody would have reported it. Some visitors would have found the site back on their system setting and wondered why. Not everything in an old system deserves to survive, but a rebuild often removes the evidence along with the junk.

Addresses work the same way. The old site had separate pages for product design, app development, and engineering, and the redesign retired them. At first each address redirected to the services section of the home page. A few days later, when the new service pages went up, we pointed each one at the page that replaced it, so /engineering/ now lands on taking over existing software. Every blog post and case study kept its address, because the files behind them stayed where they were.

Redesign, replatform, and rebuild are different decisions, and they don’t have to happen together. This was a redesign on the platform we already had, which is how we’d approach redesigning a website for anyone else, unless something underneath was genuinely in the way.

When starting over is right

None of this is an argument for keeping bad systems forever. Sometimes the foundation really is the problem. The platform may be obsolete or insecure, critical dependencies may no longer be maintained, or ordinary changes may have become disproportionately expensive. Those are meaningful reasons. “We would build it differently today” is a much weaker one.

Even a justified rebuild has to prove that it can do the same thing before it can improve anything. Meanwhile, the old system still has people using it and still needs fixes, and the longer the rewrite takes, the more the two drift apart, until the replacement is chasing a moving target. So when we do recommend one, the plan includes how the old system keeps doing its job until the new one is ready to take over.

If you’ve inherited software and the first suggestion was a rewrite, we’d start somewhere else: by reading what’s there and finding the part that’s actually in the way. The answer might still be “all of it.” But then at least you know why.