Your Old Code Is Not an Embarrassment

Somewhere around year three, founders start apologizing for their codebase.

It comes out in the first ten minutes of a call. “It’s a bit of a mess.” “We know we need to modernize.” Usually a developer has floated a rewrite, and now the founder is quietly wondering if the code their business runs on is an embarrassment.

Let me tell you about the least glamorous decade of my career. I spent ten years on one product, a .NET desktop application that grew to about 400,000 lines of code. Nothing about it would ever trend on Hacker News. While I worked on it, the industry moved to the web, then to mobile, then to the cloud. And every few years a new developer would join, look around, and say what new developers always say: we should rewrite this.

We never did. The product kept shipping the entire time. My last release there, I sat with the Product Owner and went through it feature by feature, on code that was older than some of the startups I advise now.

The unglamorous secret was a pattern called MVVM. In plain terms, the screens were kept separate from the business rules. We could rework what users saw without anyone touching the calculations underneath, and fix the logic without breaking a single screen. Boring, disciplined separation. Ten years in, we could still make a change on a Tuesday and ship it by Friday without holding our breath.

So when your developers say “rewrite,” ask them one question first: what exactly stops us from changing this code safely today? If they can name it, you can usually fix that for a fraction of what a rewrite costs. If they can’t name it, the code isn’t the problem.

Old code that still ships is an asset. Treat it like one.