Rebuild your app from scratch or save it? How to decide

To decide whether to rebuild an app from scratch or save it, first measure the actual state of the code, then compare three options: stabilize what exists, replace it gradually module by module, or rewrite everything. Gradual modernization is usually the least risky, because a full rewrite freezes product work for months and throws away years of fixes. Rebuilding from scratch is justified when the technology is no longer maintained, when the architecture cannot support what the product needs next, or when the app is locked into a platform. The decision should follow an audit, not precede it.

The information below is up to date as of October 2026.

Why does the "save or rebuild" question keep coming up?

The "should we rebuild our app?" question comes up when every change becomes slow, risky or expensive: the developer has left, the app no longer builds with the tooling the stores require, each fix breaks something else, or the original technology blocks a feature the product needs.

Often, too, a new developer suggests, in good faith, starting over "cleanly". Joel Spolsky, in Things You Should Never Do, Part I, explains why: "It's harder to read code than to write it." Wanting to rewrite is not, by itself, a diagnosis.

What are the three possible options?

For an app in trouble, there are three options: save it by stabilizing it, rebuild it gradually module by module, or rebuild it from scratch.

1. Save and stabilize. You keep the code and bring it back into shape: version upgrades, replaced dependencies, tests on critical user flows. This is often the most cost-effective option when the problem is accumulated lag rather than the design itself. For a React Native app, it typically means migrating to a recent version and to the New Architecture, as covered in our article on the New Architecture.

2. Rebuild gradually. You build the new system next to the old one and move features over one at a time, until the old code can be removed. Martin Fowler popularized this approach as the Strangler Fig, after the vine that grows around a host tree until it replaces it. On mobile, you can add React Native screens to an existing native app, which the React Native documentation explicitly supports, or install Capacitor alongside Cordova, which can coexist according to the official Capacitor guide. Two systems live side by side for a while, but every step delivers value.

3. Rebuild from scratch. You rebuild every feature in a new project, then switch users over. This is the riskiest option. It is sometimes the only reasonable one, for example for a no-code app whose code cannot be exported, as explained in our article on leaving Bubble.

Why is a full rewrite so risky?

A full rewrite is risky because it throws away invisible fixes, freezes the product and forces you to reproduce undocumented behavior.

Invisible fixes. According to Joel Spolsky, every line that looks needlessly complicated is often a fix for a bug a user ran into: "When you throw away code and start from scratch, you are throwing away all that knowledge."

Lost time. His example is Netscape: as he writes, version 6.0 is entering its first public beta, there never was a version 5.0, and version 4.0 was released almost three years earlier. Netscape's market share plummeted in the meantime. Spolsky calls the decision to rewrite "the single worst strategic mistake that any software company can make".

Behavior to rediscover. Martin Fowler, in the August 2024 version of his article, notes that the details of existing behavior are hard to figure out; this simple-sounding plan, he writes, goes "down in flames most of the time", and users can't wait for new features for the whole duration of a replacement.

Which criteria should drive the decision?

Six criteria matter when deciding between saving and rebuilding an app: code quality and tests, the state of the technology, how the architecture fits future needs, the value of what already exists, the team's knowledge, and budget versus time-to-market risk.

1. Code and tests. The question is not "is the code pretty?" but "can we change it without breaking everything?". Is the debt localized or widespread?
2. Technology. A technology that is alive but several versions behind can be migrated. An abandoned technology, or a platform with no code export, sooner or later forces a rebuild.
3. Architecture. List what the product must do over the next eighteen months (offline mode, real time, new platforms) and check whether the current app can handle it. If only one area blocks, rebuild that area, not the whole app.
4. Value of what exists. Active users, data, a well-rated store listing: the more this capital matters, the more dangerous a hard cutover becomes.
5. Team. If the team knows the code, saving it costs far less. If not, rebuilding that knowledge through an audit is usually cheaper than a rewrite.
6. Budget and timing. A rewrite is paid for twice: the project itself, and the features that won't ship in the meantime. Ask yourself what happens if the project takes twice as long as planned.

How do you combine these criteria into a decision table?

This table maps the most common situations to the option that best fits each; a single app can match two rows.

What changes when the app is on the stores?

An app published on the App Store and Google Play must be rebuilt as an update to the same listing, otherwise you lose your installed base, ratings and reviews. Four points need checking before writing the first line of code.

The same bundle ID and package name. According to Apple's documentation, once a build has been uploaded to App Store Connect, the bundle ID of an app record can no longer be changed: a new identifier means creating a new app record. According to Android Developers, if the application ID changes, Google Play treats the upload as a completely different app. The new app therefore reuses these identifiers.

The same Android signing key. An Android update is only accepted if it is signed with the same certificate. According to the Android app signing documentation, losing the key without Play App Signing makes it impossible to publish any further update. Check who holds the key, and the Apple Developer and Google Play accounts.

Ratings and reviews. They belong to the listing, not to the code, and an update keeps them. Apple lets you reset the overall rating when releasing a version; according to App Store Connect Help, this cannot be undone once the version is released, and written reviews stay visible.

Data, including on the device. Server data is migrated with a script tested in dry runs. Data stored on the device (session, preferences, drafts) is more often forgotten: an app built with another technology won't necessarily read it from the same place, so migration code is needed.

Finally, roll out gradually: Apple offers a phased release over 7 days, from 1% to 100% of users with automatic updates, and Google Play offers staged rollouts that can be halted.

What does a rewrite in React Native or Capacitor change?

Rewriting in React Native or Capacitor gives you a shared codebase for iOS and Android, but it removes neither the data migration nor the native work.

React Native fits when you start from separate native apps (Swift, Kotlin) or from an old React Native version. It renders native UI and can be integrated screen by screen into an existing app, which makes it the natural path for a gradual replacement.

Capacitor fits when most of the app is web code (Cordova, Ionic, a React, Vue or Angular site). It keeps that web code and replaces the native layer around it, often without rewriting the interface.

In both cases, specific native modules (payments, Bluetooth, third-party SDKs) have to be carried over one by one.

Why decide after an audit, not before?

The decision to save or rebuild an app should follow an audit, because the criteria above are measured in the code. An audit establishes the version lag, abandoned dependencies, where the debt sits, which tests exist, and who holds the accounts and keys.

It prevents two mirror-image mistakes: launching a rewrite when a migration would have been enough, or patching up for years an app whose technology is doomed.

Checklist before choosing between saving and rebuilding

• I have access to the code, the Apple Developer and Google Play accounts, and the Android signing key.
• I know the version lag, the abandoned dependencies and the existing tests.
• I have listed the product needs for the next eighteen months.
• I know the bundle ID and package name to keep.
• I know which on-device data must be migrated.
• I have had an audit done before choosing.

To spot the problems before deciding, see 10 signs your mobile app is badly built. If the project has already gone off track, start with Failed app rebuild: what to do now?

Getting support

To decide between saving, partly rebuilding and rebuilding, GUIGUI Tech's App Rescue Audit costs €1,500 excl. VAT and is delivered in 5 business days, for a React Native, Expo, Capacitor, Ionic or Cordova app, a React, Next.js or Vue.js web app, or code generated with Lovable or Bolt: access recovery, analysis of the code, architecture, dependencies and security, store compliance, a verdict with a costed and prioritized plan, a PDF report and a debrief call. The audit is deducted from the price of the work if you confirm within 30 days.

If your React Native app works and only needs a version upgrade, the React Native Migration Audit, at the same price, leads straight to a migration plan; it is deducted from the Full React Native Migration (from €18,000 excl. VAT, 4 to 8 weeks, fixed price) or the Expo / New Architecture upgrade if you confirm within 30 days.

For a Cordova or Ionic app, the Cordova / Ionic to Capacitor Migration starts at €9,500 excl. VAT, over 3 to 6 weeks, keeping your web code and the same bundle ID. For a Bubble, Adalo or FlutterFlow app, the Move off no-code offer starts at €15,000 excl. VAT, over 6 to 12 weeks; the firm price is set after a 2-day feasibility audit at €800 excl. VAT.