A note on the examples: many of my clients are in the middle of valuations or are actively doing business. To protect their brands and their investors, I replace names and industries with generic labels like Company A and Company B.
Your developers have told you the app needs to be rewritten from scratch. They say it’s too buggy to fix, or the framework can’t scale, or the code is too far gone. It sounds technical, so it’s hard to argue with. And a rewrite is often the most expensive decision on the whole project.
I’ve seen both outcomes. In one case I told the owner a rewrite wasn’t needed, and the monthly bill dropped by more than 80%. In another, the company’s lead pushed for a rebuild, and I carried it out myself. Here’s how to tell which situation you’re in, and the questions you can ask without being technical.
Two companies, opposite answers
Company A: the rewrite that wasn’t needed. Company A had five engineers costing about $48K a month. The lead engineer was rewriting the whole app from scratch. He told the owner that Angular couldn’t scale and the app was too buggy to stabilize.
The owner asked what I thought. I told him any framework can scale, Angular included. The real problem was that the team was writing Angular as if it were plain HTML, CSS and JavaScript, and ignoring the basics taught in Angular’s own beginner examples.
I spent a month fixing bugs and stabilizing the app that already existed. It was five Angular versions behind, so I upgraded it to the current version. As the app stabilized and new features started shipping without bugs, the owner decided to let the other engineers go. Engineering cost fell from $48K to under $9K a month, and today the app is managed for under $4K.
Company B: the rebuild that went ahead. Company B’s first version cost about $15K and was too buggy to deliver key features. A team of American contractors rewrote it, at about $37K a month for three years, roughly $1.3M in total. The second version had the same problems. It was unstable, hard to maintain, had no proper architecture, and kept putting its clients at risk.
The company’s lead and I talked it through, and he pushed for a rebuild. I rebuilt the backend and frontend myself over 14 months, keeping about a quarter of the existing code. Maintenance dropped below $8K a month, then under $2K.
Why the answers were different
In Company A’s case, the app worked. It had real users and real features. What was broken was how the team wrote it, and that could be fixed in place. In Company B’s case, the problem was the foundation itself. The app had no proper architecture, and a second full build by a different team hadn’t changed that.
The situations were different, and so were the answers. I looked at how each system was actually built, not at the story people told about it.
What a rewrite really costs
The estimate for a rewrite usually covers building the new app. It rarely covers everything else.
While the new version is built, you keep paying to run the old one, because customers still depend on it. New features slow down or stop, since the team is busy rebuilding what already exists. The rewrite also brings its own bugs, and the team has to relearn every odd rule the old code quietly handled.
Even a well-run rebuild takes time. Company B’s rebuild ran 14 months, and that was with a quarter of the code kept. If someone quotes you “a few weeks” to rewrite a working product, ask what they’re leaving out.
Five questions to ask before you approve a rewrite
1. What exactly is wrong, in plain words? “It can’t scale” and “it’s too buggy” aren’t reasons. Ask for specifics: which part fails, how often, and what it costs you. If nobody can name the limit, the claim is probably an opinion.
2. What works today? Your customers are using something. List what they rely on, and ask how much of it survives the rewrite. In Company B’s rebuild, about a quarter of the code was worth keeping. A rewrite that throws away everything also throws away what you already paid for.
3. What does one small change cost? Ask how long a minor feature takes, and how often it breaks something else. If small changes touch everything, the structure is the problem, and that points toward a rebuild. If changes are slow only because the team doesn’t know its tools, that points toward training and repair.
4. Who benefits from the answer? I’m not saying anyone is acting in bad faith. But a rewrite means months of billable work for whoever does it, and the person recommending it is often the one who wrote the original. Ask for a second opinion from someone who gets paid the same either way.
5. What does each path cost, in dollars and months? Ask for an estimate to stabilize and an estimate to replace, each with a timeline, what you keep, and what the app costs to run afterward. Then add the cost of waiting, because you pay for the broken version every month the decision drags on.
What to ask for in writing
- A one-page plain-language explanation of the problem
- A list of what would be kept and what would be replaced
- Two estimates, repair and rebuild, with timelines
- The monthly cost to maintain the app after each option
If a team can’t produce these, you don’t have enough information to approve a rewrite.
The short version
Repairing is cheaper most of the time. When a rebuild is the right call, you should see why in numbers, and you should keep whatever is worth keeping. I recommend whichever costs you less, and I’ll say so even when that means no rewrite and a much smaller bill.
If your team has told you to start over, book a free 15-minute call. You’ll know whether to repair or rebuild, and roughly what it’ll cost.