Mobile Apps

Redesigning or Rebuilding an Existing App: When to Patch and When to Start Over

By Daniyal Hassan · · 11 min read

If you have inherited an app that crashes on mid-range Android phones, or you paid a team in 2021 and the app now feels slow, ugly, and impossible to update, this post is for you. The rebuild vs fix existing app decision is the single most expensive call a non-technical founder makes, and most people get it wrong in both directions — they rewrite when a patch would do, or they keep patching a foundation that should have been demolished. Below is the exact framework we use with Pakistani founders to decide, plus honest PKR numbers so nobody sells you a rebuild you do not need.

First, separate the three things people lump together

Half the confused conversations we have start because “the app is bad” means four different problems wearing one coat. Before you spend a rupee, name which one you actually have:

  • Redesign — the logic works, but it looks dated, the flow confuses users, and conversion is poor. This is a UI/UX problem, not an engineering one.
  • Fix / patch — specific bugs, crashes, a broken payment integration, a screen that does not load. The architecture is fine; the wiring is loose.
  • Rebuild — you keep the product idea and most of the design, but throw away the codebase and build it again on a modern foundation.
  • Rewrite + replatform — same as rebuild, but you also change the technology, for example you migrate the app to React Native from two separate native codebases to save long-term cost.

These cost wildly different amounts. A redesign of an app that already works might run PKR 250,000–600,000. A full rebuild of a real product with payments, auth, and a backend starts around PKR 1,200,000 and climbs from there. If a vendor quotes you the same number for “fix” and “rebuild,” they have not actually looked at your code.

The rebuild vs fix existing app decision framework

Run your app through these questions in order. The first “yes” that lands in the rebuild column usually settles it.

1. Can your current team (or any team) safely change the code?

Ask whoever maintains it to add a small feature — say, a new field on the signup form. If a two-line change takes a week, breaks three unrelated screens, or nobody dares touch it, the codebase has lost the property that makes software valuable: changeability. That is the strongest single signal to rebuild the legacy app rather than keep patching it.

2. Is the technology stack still supported?

Apps built on abandoned frameworks (old hybrid frameworks, unmaintained UI libraries, a backend on a PHP version that is end-of-life) are not just dated — they are a security and store-compliance liability. Google Play and the App Store both reject updates that target old API levels. If you cannot ship an update at all, “patch” is not on the table.

3. How much of the cost is the codebase vs the product knowledge?

Here is the counterintuitive part most founders miss: your real asset is rarely the code. It is the product logic, the edge cases you discovered the hard way, your user data, and your designs. A rebuild keeps all of that and discards only the code — which is the cheapest, most replaceable part. Founders cling to bad code because they confuse “we paid a lot for this” with “this is worth a lot now.” It is a sunk cost. Ignore what you spent; decide on what it costs you going forward.

4. What does the bug pattern look like?

  • Bugs are isolated and reproducible → patch. You have a maintainable app with normal defects.
  • Fixing one bug reliably creates another → this is the classic symptom of tangled architecture, and it means a fix broken app approach will bleed money forever. Rebuild.

5. Is the data model fundamentally wrong?

You can repaint a house. You cannot repaint a foundation that was poured in the wrong place. If the database structure cannot represent what your business now needs — say, you started single-vendor and now need a marketplace — no amount of patching fixes that. The data layer dictates everything above it.

When patching is the right, honest answer

We say “do not rebuild” more often than you would expect, because a rebuild that was not needed is the most wasteful thing in this industry. Patch — and possibly redesign the surface — when:

  • The core works and users actually transact (JazzCash/Easypaisa payments clear, orders complete).
  • The complaints are about looks and flow, not stability — that is a job for UI and design work, not a new codebase.
  • The stack is current and a competent developer can read and extend it within a day of onboarding.
  • Crashes trace to two or three specific, findable causes rather than “everything is fragile.”

In these cases a targeted sprint — fix the crashes, refactor the worst two modules, restyle the key screens — gets you 80% of the benefit at 20% of the cost of a rebuild. Anyone who skips straight to “you need to start over” without offering this option is optimising for their invoice, not your business.

When you should genuinely start over

Rebuild when two or more of these are true at once:

  1. No developer will warranty changes to the existing code because they cannot predict what breaks.
  2. The framework or backend is end-of-life and blocking store updates.
  3. You are paying more in monthly maintenance and downtime than a rebuild would amortise over a year.
  4. The original developer is gone and left no documentation, no source control history, and a build process only they understood. (This is depressingly common with apps inherited from a freelancer who has moved on.)
  5. Your roadmap needs features the current architecture physically cannot support without surgery deeper than a rebuild anyway.

If you are in this position with an app that never launched properly or stalled mid-development, what you actually need is a rescue failed app project engagement — a structured takeover where someone audits what exists, salvages the data and designs, and rebuilds the parts that are unrecoverable. That is a specific kind of mobile app development work, not a normal greenfield build, and it should be priced and scoped as a rescue.

The replatform question: should you migrate the app to React Native?

If you are rebuilding anyway, this is the moment to decide on technology. The most common smart move we recommend for Pakistani founders is to migrate the app to React Native (or Flutter) so you maintain one codebase for both Android and iOS instead of two. For most apps — anything that is not a heavy game or AR product — a single cross-platform codebase cuts your long-term maintenance bill roughly in half and means a single fix ships to every user.

The honest caveats: if your app depends on deep platform-specific hardware features, or you already have a working native iOS app and only Android is broken, a full cross-platform rewrite may be overkill. Replatform because it lowers your future cost, not because the framework is fashionable.

How to run the decision without getting fleeced

Never let the same vendor who profits from a rebuild be the only one telling you a rebuild is necessary. Protect yourself:

  • Get a code audit first, as a paid deliverable, separate from any build contract. A few days of a senior engineer reading the codebase produces a written verdict: patchable, rebuild, or replatform — with reasons. This costs a fraction of a wrong rebuild.
  • Demand a recommendation against their own interest. A trustworthy partner will tell you when a patch is cheaper. We routinely send founders away with a PKR 300,000 fix instead of a PKR 1.5m rebuild because that was the right call.
  • Ask for the salvage plan in writing. Which of your data, designs, and API contracts survive? If the answer is “we start from zero on everything,” push back — your user data and design system should almost always carry over.
  • Insist on source control and documentation as deliverables this time. The reason you are stuck is usually that the last team left none. Do not repeat it.

A rough cost and timeline reality check (PKR)

These are honest order-of-magnitude figures for the Pakistani market, not quotes. Your real number depends on payment integrations, backend complexity, and how much salvage is possible:

  • Targeted bug-fix sprint: PKR 150,000–400,000, 2–4 weeks.
  • Redesign of a working app (UI/UX, no rebuild): PKR 250,000–600,000, 3–6 weeks.
  • Code audit + rescue assessment: PKR 80,000–200,000, about 1 week — and it is the best money you will spend because it prevents a wrong six-figure decision.
  • Full rebuild / replatform to React Native: PKR 1,200,000 and up, 8–16+ weeks depending on scope.

Notice the audit cost. Spending one week and a small fee to know the answer is almost always cheaper than guessing wrong on a project ten times the size.

Frequently Asked Questions

My developer disappeared and left no documentation. Can the app still be saved?

Usually yes, at least partially. Even without documentation, a senior engineer can decompile, read the codebase, and recover the data model and API behaviour. Whether we patch or rebuild depends on what we find, but your user data and any design assets almost always survive. This is exactly the kind of rescue takeover we handle regularly.

Is it cheaper to fix the existing app or rebuild from scratch?

Fixing is cheaper when the architecture is sound and the bugs are isolated — often a quarter of the cost of a rebuild. It becomes more expensive than rebuilding when every fix breaks something else, because you pay for the same defects again and again. The only honest way to know is a short code audit before committing to either path.

We have a native Android and a native iOS app that are both hard to maintain. Should we migrate to React Native?

For most non-game apps, yes — moving to a single cross-platform codebase roughly halves your ongoing maintenance cost and means one fix ships to both platforms. The exception is apps that lean heavily on platform-specific hardware or performance. We will tell you honestly which camp your app is in rather than push the framework by default.

Will rebuilding lose my existing users and their data?

No, if it is planned properly. A competent rebuild migrates your existing database so current users keep their accounts, history, and balances. The risk only appears when a team rebuilds carelessly without a data migration plan, which is why we put the migration in writing before any code is touched.

How long before I see results after a rebuild?

A focused rebuild typically reaches a launchable version in 8–16 weeks depending on scope, with a working internal build to test much earlier. A patch or redesign can ship in 2–6 weeks. We sequence work so the most painful problem — usually crashes or a broken payment flow — gets fixed first, not last.

How do I know your recommendation is honest and not just upselling a rebuild?

Start with a paid audit that is contractually separate from any build work, so our recommendation does not depend on selling you the bigger project. We routinely recommend cheap patches over expensive rebuilds when that is the right call, and our public Google reviews reflect that we tell clients no. If a vendor cannot recommend the cheaper option, that tells you something.

Talk to One Source Soft before you spend on the wrong path

The most expensive mistake here is deciding in the dark — rebuilding what you could have patched, or patching what you should have rebuilt. We have been making this call for Pakistani founders since 2009, across Karachi, Lahore, Islamabad and beyond, and our first job is to give you a straight answer about whether your app needs a fix, a redesign, a rebuild, or a full rescue.

Book a free consultation and app audit. We will look at your actual codebase, give you an honest verdict with PKR numbers, and recommend the cheapest path that actually solves your problem — even when that means we earn less. Read what other founders say in our public Google reviews, then get in touch or learn more about our mobile app development services. No rebuild you do not need, no jargon, no pressure.

Related reading

Keep reading