Rewrite or rescue? How to decide what to do with a struggling app

Every once in a while I get the same call. The app works, sort of, but every change takes longer than the last one. Releases break things that used to be fine. New engineers take weeks to get productive. Someone on the team has started saying the word “rewrite,” and now there is a real decision on the table that could cost a year and a large budget.

Here is how I think about that decision, after 9 years of building and fixing iOS apps.

The rewrite is almost always more expensive than it looks

A rewrite feels clean. You get to leave the old mess behind and do it right this time. That feeling is the trap.

When you rewrite, you are not just rebuilding features. You are rediscovering every small rule your app learned over the years. The odd edge case a customer reported in year two. The workaround for a payment provider that returns the wrong status code. The reason one screen loads its data in a strange order. None of that is written down. It lives in the current code, and a rewrite throws it away and hopes to find it again by shipping bugs to your users.

Most rewrites also freeze your product. For the months or years it takes, your old app still needs fixes and your new app is not ready, so you pay for two codebases and ship value on neither. Teams underestimate this every time.

I am not saying never rewrite. I am saying the bar should be high, and you should only clear it with evidence, not with frustration.

When a rewrite is actually the right call

There are real cases for starting over. A few I would take seriously:

The platform or framework is dead or dying, and staying on it blocks you from the OS features your users now expect.

The app is small enough that a rewrite is a few weeks, not a few years. Small apps are cheap to redo and the risk is low.

The original architecture makes a core new direction impossible, and you have checked that with someone who read the actual code, not someone who just heard it was old.

Notice what these have in common. They are specific and they are checkable. “The code is a mess and I am tired of it” is not on the list, because that feeling is true of almost every app that has shipped for a few years, including healthy ones.

The middle path most teams miss

Between “keep suffering” and “burn it down” there is a third option, and it is the one that fits most apps: fix the parts that actually hurt, in the order they hurt, without stopping your roadmap.

This works because the pain is almost never spread evenly. In most apps I look at, a small number of files and decisions cause most of the cost. Two or three screens have grown into single classes of two thousand lines. One old data layer everything depends on. A handful of places where the app crashes on purpose instead of recovering. A test suite that covers the safe code and skips the risky code.

You do not need to rewrite an app to fix those. You need to know exactly which ones they are, how much each one is costing you, and what order to fix them in so that each fix ships on its own and pays for itself. That is a plan, not a demolition.

How to get the evidence before you spend the money

This is the part teams skip, and it is the cheapest part. Before you commit to a rewrite or a rescue, get an independent read on the code from a senior engineer who does this for a living.

That is what my app audit is for. I go through your codebase and your app for one to two weeks and give you a scored report across five lenses: architecture, code quality, performance, stability, and delivery pipeline. You get a clear picture of where the real risk sits, what it is costing you, and a prioritized fix plan your own team can act on. If the honest answer is that a rewrite is right, the report will say so, with reasons. If the honest answer is that a targeted rescue is cheaper and safer, it will say that instead, and it will tell you where to start.

The audit is a fixed price of €790 and there is no lock-in. You can read a full nine page sample I did on a large open source app on the audit page. It is the exact format you would get for your app.

The short version

Do not decide with your gut on a call this expensive. A rewrite might be right, but the odds are against it, and the way to know is to read the code before you spend, not after. Get the evidence, then choose.

If your app is slow, crashing, or expensive to change, and you are weighing what to do next, that is exactly the decision an audit is built to answer.