Shimira IT
When a software project has gone wrong, almost every vendor you call will tell you the same thing: the existing code is a mess, and the fastest path forward is to start again.
Sometimes they're right. Often they're not. And it's worth knowing that "rewrite it" is also the answer that's easiest to say, quickest to scope, and most profitable to sell. A rewrite lets a vendor skip the hard, unglamorous work of understanding what someone else built.
Here's how to make the call on evidence rather than instinct.
Why rewrites are more dangerous than they look
Rewriting feels clean. You get to do it properly this time, without the compromises. That feeling is exactly why rewrites overrun so often.
Three things go wrong:
You lose invisible knowledge. Working software accumulates fixes for problems nobody documented: the odd tax rule, the customer who needs a special case, the retry that stops a payment failing. That knowledge lives in code that looks untidy. A rewrite discards it, and you rediscover each problem in production.
You rebuild everything, not just the broken part. The login, the admin panel, the reports, the exports, the email templates. All of it worked. All of it gets rebuilt.
Nothing improves until the very end. During a rescue, customers see fixes within weeks. During a rewrite, they see nothing until the new system replaces the old one, and if the rewrite overruns you're maintaining two systems at once.
None of this means never rewrite. It means the burden of proof sits with the rewrite.
When a rewrite genuinely is the right call
There are real cases. Look for these:
- The data model can't support what you need. If the fundamental structure of the data is wrong (say, the system assumes one user per account and your business now requires teams), that change touches everything. This is the most common legitimate reason.
- Security can't be retrofitted. Where authentication and access control were never designed in, adding them safely can amount to rebuilding the core anyway.
- The technology is genuinely dead. A framework with no security updates and no available developers isn't a preference problem, it's a risk you can't patch.
- Nobody can build or deploy it. If the build is broken, dependencies can't be installed, and there's no documentation, recovering it can cost more than replacing it. Worth trying for a few days first; this is sometimes fixable in hours by someone who has seen it before.
- The scale required is a different problem. Something built for 100 users that now needs 100,000 sometimes needs different architecture, though far less often than people assume.
Notice what isn't on that list: code that looks ugly, a language your new vendor doesn't like, missing tests, or an old but supported framework. Those are reasons to improve, not to restart.
Five questions that decide it
Answer these honestly, ideally with a technical assessment in hand.
1. Does it work today, even partly? If customers are using it, it has value that a blank page doesn't. Start from what works.
2. Can a competent developer change one thing safely? The real test isn't whether the code is pretty. It's whether a new engineer can make a small change without breaking three other things. If they can, it's maintainable.
3. Is the data model roughly right? Data structure is the expensive thing to change. If the shape of the data broadly matches your business, the rest is fixable.
4. What percentage actually needs replacing? Part-by-part, not overall. Often the answer is "the payment handling and the permissions system", which is a rescue with two rebuilt components, not a full restart.
5. What does each option cost, in time and money? Get both estimated. If rewriting costs three times as much and delays fixes by four months, the bar for choosing it should be high.
The third option most vendors skip
The choice isn't binary. The approach that works most often is stabilise, then replace in pieces.
- Fix what's actively broken, so you stop losing customers now.
- Put the critical flows under test, so changes stop causing regressions.
- Replace the worst parts one at a time, while the system keeps running.
- Decide later whether anything is left that still warrants a rewrite. Frequently there isn't.
This gives you working software throughout, spreads the cost, and lets you stop when the product is good enough rather than committing upfront to a fixed rebuild.
How to tell a good assessment from a sales pitch
Before accepting any recommendation, look for these:
- A part-by-part verdict, not one sweeping judgment. "The data model is sound, the payment handling needs rebuilding, the front end needs tidying" is a real assessment.
- Reasons you can check. "It's badly written" is an opinion. "Access control is enforced only in the browser, so any user can read other users' records" is a finding you can verify with a second opinion.
- Both options costed. A vendor confident in their recommendation will happily price the alternative.
- A written report you keep. If you can't take it to another vendor, it's a sales document.
- A willingness to say you need less help than you feared. The most trustworthy answer we ever give a prospect is "this is in better shape than you think."
A vendor who recommends a rewrite after one call, without reading the code, is guessing.
What this looks like in practice
A typical honest outcome on a stalled project: the database structure is fine, the front end is workable but untidy, the payment integration is unreliable and should be rebuilt, and there's a security problem in how user data is exposed that needs fixing this week.
That's a rescue with one rebuilt component. Weeks of work, not months. The version where someone rebuilds all of it because the front end is untidy costs several times more and delivers the same product.
Getting an answer you can trust
Our software project rescue service starts with a fixed-price take-over audit, typically $2,000–$5,000 depending on the size of the system. You get a written report with a fix-or-rewrite call for each part of the system and the reasoning behind it, and it's yours to keep even if you take it to another vendor.
If your app was built with an AI tool like Lovable, Bolt, or Replit, the questions are slightly different, and a rewrite is almost never the answer: your prototype is the most precise specification you'll ever have. See AI-built app rescue.
And if your developer has stopped replying, start with what to do when your software developer disappears: recovering access comes before any decision about code.