Almost every product owner has heard at least once from their team: “We need to rewrite everything.” And each time, the same question arises: is this really justified—or can the problem be solved without “burning the project”?
We’ve heard similar statements from fellow programmers more than once. Sometimes projects truly had to be rewritten, and sometimes, on the contrary, they had to be pulled out and “resuscitated.” And resuscitation doesn’t always start with the code… but we’ll get to that later.
Listen to the Team
The most common mistake a product owner makes is ignoring signals until the situation becomes critical. If a problem can be caught in the bud, do it. Listen carefully to what the team is saying. It doesn’t matter whether they’re newbies or seasoned professionals: you need to listen to everyone, especially if it’s your area of responsibility.
Find the Cause
The first step is to understand why the “we need to rewrite” was said in the first place.
If it’s just one person’s whim, don’t bother. If more than one person says so, double-check: call a third person and discuss the arguments. If half the team is suggesting a “rewrite,” there’s definitely a problem. But then the key question is: will a rewrite help, or is it just an emotional statement?
There is a reason, but is it compelling enough?
Let’s look at the main typical situations that usually trigger a team to push for a rewrite.
1) “The codebase is outdated.”
This phrase sounds ominous, but it’s often too abstract. What exactly is outdated—a library, a plugin, a language version? If we’re talking about dependencies, updating them is usually enough. If the language version is outdated, raise the values in the configuration files. Yes, something will break. Yes, you’ll have to fix it. But rewriting the entire project just because of this is a highly questionable idea.
Verdict: no need to rewrite. Focus on updating dependencies selectively.
2) “It’s too difficult to add new functionality.”
Now that’s a serious signal. In a large project, slow feature implementation costs financial and reputational losses. A successful IT project relies on flexibility.
In small projects, a feature is often rolled out in 2-3 days, sometimes even in one. In larger projects, the cycle extends to weeks: something small might reach release in 4-5 days, while something larger might wait two weeks.
But if a new feature is rolled out in half the potential development time of a “copy of the current project,” that’s abnormal. There’s definitely a problem. And yes, it could be in the code, but in my experience, it’s often not the code that’s the problem, but the processes.
Development Processes
How does a feature get into production? Is it tested? Who tests it? How does a tester know when it’s time? Is there a code review—when a more experienced person looks at what the developer submits? Who estimates task deadlines? Who verifies the adequacy of these estimates?
These are basic things, but they are often ignored by startups and small IT companies. As a result, “bad” projects are built, which inevitably create problems. On the surface, it seems like they’re “saving the client money” (and the client often thinks so too), but in reality, the money is simply wasted. The realization comes too late.
The reason for this is clear: everyone is chasing a quick buck and covering cash flow gaps. But this cycle won’t end until they close down/go bankrupt/go outsourcing—or restructure their development and task estimation processes.
Verdict: If feature development takes an unreasonably long time, review your internal team processes. Development can really be transformed into a production line where most things are transparent and understandable.
3) “Every new feature breaks everything”
This is a little less scary than the previous point, but it has a hidden agenda.
On the one hand, implementing testing can sometimes solve the problem. And I’m not talking about manual testing—that should be in place anyway. Unit tests and automated regression testing are needed. Yes, the development cycle will become longer, and releases will be slower, but the code quality will increase exponentially, and the team’s processes will become noticeably more stable.
On the other hand, if tests haven’t helped, or you’ve gradually slipped into problem #2 (everything is taking too long), then it makes sense to consider a business process audit.
Verdict: implement tests first. If that doesn’t help, the problem is almost certainly in the processes.
4) “The project is slow and can’t handle the load.”
If users complain about speed, and the server crashes when traffic increases, this is a business problem directly impacting revenue.
This is often treated with optimization: caching, optimizing database queries, increasing server resources. But sometimes a project is so poorly written from the start that it’s easier to rewrite critical sections, especially when processes are uncontrolled.
A classic example: a problem can be solved with a single SQL query, but interns like to “fence” it: instead of a single query, they create hundreds of queries in a loop. I did this myself when I was new and inexperienced—and many of my colleagues have experienced the same. If you have poor supervision over newcomers, there could be dozens of such spots in a project.
Verdict: First, find the problem areas and try optimization/cache.
If that doesn’t help, rewrite the bottlenecks, not the entire project.
Result
- Is the codebase outdated? Update dependencies, don’t rewrite.
- Is it difficult to add functionality? Optimize your development processes.
- Is every feature breaking everything? Implement tests → if that doesn’t help, go back to the processes.
- Is the project slow? Optimize → if that doesn’t help, rewrite the bottlenecks (not the entire project).
- Want new technologies? That’s not a reason for rewriting.
The main rule: rewriting is always a risk and a big investment. In my experience, only small projects have been rewritten from scratch, where the cost of reworking the entire project is no more than two weeks. In large systems (really large ones, not online stores or CRMs), a complete rewrite is almost impossible: no one will spend that much money on development.
Don’t let programmers trick you into unnecessary rewriting – but you can’t ignore real problems either.
