Rebuilding is not the answer

Have you ever had a plumber come to your house, take one look at the pipes, and say, “What on earth did the last guy do?”

Software engineers often have the same reaction when looking at an unfamiliar codebase. And all too often, their next move is: “This needs a complete rebuild. Give me six months, and I’ll deliver something that actually works.”

It’s an easy trap to fall into. Engineers are naturally inclined to rewrite rather than work with existing systems. But here’s the reality:

• Even in its current state, your application delivers value.
• Significant time and effort have already been invested in the business logic.
• A rebuild comes with no guarantee of avoiding past mistakes.
• That “six-month” timeline? It’s usually an underestimation. As complexity emerges, corners will get cut, and you’ll end up in the same situation—just with a new codebase.

So, what’s the alternative?

Find an engineer willing to work with the codebase rather than replace it. Someone with a track record of improving systems incrementally.

As a founder, you want to ship new features. A great engineer will challenge you: “If we prioritise Feature X now, that means delaying updating framework Y, which could slow us down later.” Collaborate on deciding the best attack plan to revive your application. The answer should not be weeks of feature development, nor should it be months of getting rid of technical debt.