Upgrade Your React Native App or Rewrite It From Scratch in the AI Era

Key takeaways:

Every fintech team with an aging React Native app eventually asks the same question: do we upgrade what we have, or rewrite it from scratch? AI changes the math, but not the way most people assume. AI sharply lowers the cost of the mechanical work an upgrade is mostly made of, and it quietly adds cost to a from-scratch rewrite through review, oversight, and drift remediation. The other thing AI does not change is that you cannot make this decision safely on a codebase you cannot measure. Before you choose, you run four steps: cover the money paths with unit tests, add end-to-end tests on the critical journeys, run a technical audit, and inventory your end-of-life libraries. Those steps tell you which decision you actually have, and they are the safety net that makes either path survivable.

• AI lowers the cost of an upgrade more than a rewrite, because upgrades are mostly mechanical and rewrites are mostly judgment.
• AI also adds cost: every agent change on a money path needs human review, and drift grows with task size.
• You cannot decide upgrade-versus-rewrite on a codebase you have not measured first.
• Four prerequisite steps: unit-test the money paths, add end-to-end tests, run a tech audit, and check for end-of-life libraries.
• If you rewrite from scratch, that test suite is your only proof the new app behaves like the old one.

Introduction

The rewrite-from-scratch instinct is loudest right after a painful sprint, and AI has made it louder. Every eighteen months or so a fintech CTO looks at a React Native app that has become slow to build and painful to change, and now there is a new temptation on top of the old one: surely an AI agent can just regenerate the whole thing clean. It cannot, and believing it can is how teams talk themselves into the most expensive version of this decision. AI is genuinely powerful here, but it helps an upgrade far more than a from-scratch rewrite, and it introduces new costs that do not show up until the review queue backs up. This guide lays out where AI cuts cost and where it adds it, the steps you must run before you decide anything, and why testing is the part you cannot skip, especially if you rewrite.

Upgrade or rewrite from scratch: what is the real difference?

Strip away the frustration and one question decides it: is the problem the code, or the foundation? An upgrade keeps your existing app and modernizes it in place, moving to the current architecture, replacing weak modules behind stable boundaries, and shipping the whole time. It is the right call when the foundation, meaning the framework, authentication model, data layer, and navigation, is sound and only the code on top has decayed. A rewrite from scratch starts a new codebase and rebuilds from zero. It is defensible only when the foundation itself is structurally wrong, such as an abandoned framework with no upgrade path or a data model the business has outgrown.

Most teams have a code problem and talk themselves into a foundation problem, because the code problem is the one they feel every day. The distinction matters more than ever in the AI era, because AI is spectacularly good at the mechanical work an upgrade needs and much weaker at the judgment a from-scratch rewrite demands. Get the diagnosis wrong and you point the most expensive tool at the wrong job.

Where AI cuts cost, and where it quietly adds it

Here is the part most rewrite pitches skip: AI does not just reduce cost, it moves cost around, and in a regulated app some of the places it moves cost to are expensive. Treating AI as a pure discount is how a rewrite budget blows up in the second quarter.

AI is cheapest exactly where an upgrade lives. Dependency bumps, framework-version migrations, New Architecture codemods, converting class components to hooks, adding TypeScript types, and generating test scaffolding are mechanical, pattern-based transforms that agents now apply across hundreds of files faster and more consistently than a human team. Agents also accelerate the boring, high-value parts of the audit: reading an unfamiliar codebase, mapping dependencies, and drafting characterization tests. That is real money saved, and it is why AI tilts the economics toward upgrading.

But AI adds cost in three places that a from-scratch rewrite maximizes. First, review. Every agent change that touches a money path or a compliance flow has to be read by a senior engineer, because an agent has no scope reflex and will confidently delete a load-bearing guard it thinks is redundant. The more code an agent generates, the larger that review surface grows, and a from-scratch rewrite generates the most code of any option. Second, drift remediation. On large, long-running tasks agents wander, and someone has to catch and fix the plausible-but-wrong output before it reaches production. Third, setup. Getting useful, safe output requires senior time up front to define seams, invariants, and evals, and that cost is paid before the first line ships.

The net is the point. AI lowers the cost of an upgrade a lot, because an upgrade is mostly the mechanical work AI is best at. It lowers the cost of a from-scratch rewrite less, because a rewrite is mostly judgment, re-earned correctness, and review, which is where AI adds cost and risk. So in the AI era the economic gap between the two paths widens in favor of upgrading, not the reverse. The teams that assume AI makes a clean rewrite cheap have the causation backwards.

Before you decide anything: the steps you must run first

You cannot make this call on a hunch, and you especially cannot point an AI agent at a codebase you have not measured. Run these four steps first. They are valuable whether you end up upgrading or rewriting, they are what makes AI safe to use, and together they tell you which decision you actually have.

Cover the money paths with unit tests. Start with characterization tests: tests that capture what the code does today, not what you wish it did. The old app’s behavior on card authorization, transfer limits, fee calculation, and KYC decisioning is your real specification, and most of it is written down nowhere else. Pin it in tests before you change or regenerate anything. AI can draft these fast, but a human confirms each assertion against intended behavior.

Add end-to-end tests on the critical journeys. Unit tests miss integration failures, so cover the flows that move money or gate access end to end: onboarding, login, KYC, funding, transfer, payment. Tools like Detox or Maestro drive the real app the way a user would. [VERIFY current recommended RN e2e tooling] These tests are what tell you the whole path still works after a change, not just an isolated function.

Run a technical audit. Assess the things that decide the upgrade-versus-rewrite question: is the architecture sound, how far behind is the React Native version, where are the complexity and crash hotspots, what is the security posture, and what are the performance baselines. This is where AI earns its keep by mapping the codebase quickly, and where a senior engineer earns theirs by judging what the map means.

Check what libraries are end of life. Inventory every dependency and flag the ones that are unmaintained, abandoned, or incompatible with a current React Native and the New Architecture. End-of-life libraries are often the real forcing function: a single critical dependency with no maintained successor can turn a comfortable upgrade into a partial rebuild of that subsystem, and knowing that before you commit changes the plan.

Only after these four steps do you actually know whether you have an upgrade or a rewrite on your hands. You also now hold the thing that makes either path survivable: a test suite that captures how the app behaves today.

Especially if you rewrite from scratch: tests are your only safety net

If you upgrade, the existing code is a reference you can diff against when something looks wrong. If you rewrite from scratch, that reference is gone the moment you open the new repo, and the old app’s behavior, most of it undocumented, becomes a specification you have to reconstruct from memory. That is where from-scratch rewrites silently fail: not on the features anyone remembered to write down, but on the transfer edge case, the rounding rule, and the compliance branch that lived only in code nobody re-read.

This is why the test suite from the steps above is not optional for a rewrite, it is the whole safety net. The characterization and end-to-end tests you wrote against the old app become the acceptance criteria for the new one. The new build is not done when it looks right, it is done when it passes the suite that proves it behaves like the app it replaces. It is also why a from-scratch rewrite costs more than it looks: you have to build that test net regardless, and then satisfy it a second time in a brand-new codebase. An upgrade satisfies it once, in place.

The strongest case for each path

It would be dishonest to pretend either path is always right, so here is the real case for both.

The case for upgrading is that your old app is load-bearing, not just ugly. What looks like mess is usually accumulated correctness: retry logic on failed authorizations, device-specific fixes, transaction-integrity guards, and compliance flows that took multiple reviews to sign off. Joel Spolsky called rewriting from scratch the single worst strategic mistake a software company can make, and it is worse in fintech, where you also reset a hard-won security and audit posture to zero. An upgrade keeps shipping the whole time and never opens a gap between the app users run and the one you are building.

The case for rewriting from scratch is that some foundations cannot be saved. An app pinned to an abandoned framework, wired to native modules that no longer compile, or built on a data model the business has outgrown is a demolition, not a refactor. A clean start lets you adopt current architecture from day one and drop years of dependency weight, and companies like Mercari and Float have publicly described greenfield React Native rebuilds for exactly that reason. When where you are going differs sharply from where you are, bolting the new onto the old can cost more than starting clean.

The middle path: extract the core, rewrite the shell

The upgrade-versus-rewrite binary hides the option that usually wins. A fintech app is really two layers with different risk. The load-bearing core is the business logic: money-path rules, validation, KYC and AML checks, authentication, cryptography, data models, and API contracts. The shell is everything the user touches: screens, navigation, state, the design system. They almost never need the same treatment.

The move is to extract the core into a versioned internal SDK with a clean, typed API and carry it across mostly intact, then rewrite the shell lightweight on current architecture against that stable core. You get a modern front-end without re-earning your compliance and security posture, because the audited logic did not change, it just moved behind a boundary. The catch to name up front: this only works if the core is separable. When validation lives inside a screen and a money rule hides in a button handler, step one is the untangling, pulling logic into a clean core module with the characterization tests from earlier capturing behavior before you move it. That extraction is the highest-value work in the project, and it is what makes both an upgrade and a partial rewrite safe.

Agents or by hand: how to actually do the work

The execution choice mirrors the cost section. Agents own the mechanical bulk: dependency upgrades, the New Architecture codemods, class-to-hooks conversions, pattern translation across many files, and test scaffolding. Humans own judgment: designing the seams, defining the invariants, and reviewing every change that touches money or compliance. This is guardrails-first work, the same discipline behind shipping AI agents to production: humans set the boundaries, agents transform inside them, humans review the risk-bearing changes. Framed as a human-in-the-loop versus on-the-loop question, mechanical codemods can run on-the-loop in monitored batches while money-path edits stay in-the-loop and reviewed before merge.

The teams that get burned sit at the extremes: point an agent at the whole repo and let it run, or do everything by hand and spend a year. The blend does the upgrade in a fraction of the time without betting the money paths on an agent’s judgment, and the core-SDK split above is what makes it safe, because once the audited core is isolated, agents can move fast across the shell while the risky code stays under tight review.

Whose call is this, really?

The decision looks like one call and is really five, which is why the meeting stalls. Each stakeholder optimizes for a different risk, and aligning them is half the work.

Four situations, four verdicts

The aging but healthy app. Several versions behind, slow builds, bloated dependencies, but sound architecture and data layer. Verdict: upgrade in place. The pain is code and tooling, not foundation.

Two merged codebases after an acquisition. Two apps, overlapping features, two compliance flows. Verdict: a targeted rewrite of the merged surface done as a strangler, preserving each app’s compliance logic by migrating it deliberately rather than reimplementing from memory.

The startup that outgrew its MVP. Real money now flows through code that was built fast to find product-market fit. Verdict: depends on the foundation. Sound core with shortcuts on top means upgrade; hardcoded single-region or single-tenant assumptions the business has outgrown mean a rewrite of the affected core. The trap is rebuilding the “embarrassing” MVP for pride, not engineering.

Moving off React Native entirely. Verdict: a rewrite by definition, so it needs a capability React Native genuinely cannot deliver, not just frustration with the code. Otherwise you rebuild the mess in a new language.

When does bringing in a partner make sense?

Counterintuitively, the upgrade is the harder thing to execute, not the easier one. A from-scratch rewrite lets a team work in a clean room. An upgrade asks them to change the engine while the plane is flying, on unfamiliar code, without breaking a regulated money flow, and to wield AI agents on that code without letting them drift into an incident. That is senior work.

That is what Teamvoy takes on. Senior mobile and platform engineers come in, run the test-and-audit steps above, stabilize the existing React Native app, drive the New Architecture migration with agents where it is safe and by hand where it is not, and replace modules behind stable seams while your product team keeps shipping. We treat the old code as evidence, not garbage, the same way we approach moving AI features from pilot to production and the strangler pattern for legacy systems. The goal is a modern app your team fully owns, reached without a revenue-risking cutover.

Conclusion

In the AI era the upgrade-versus-rewrite question has a clearer answer than it used to, as long as you read the economics correctly. AI lowers the cost of an upgrade far more than a from-scratch rewrite, because upgrades are mechanical and rewrites are judgment, and AI adds real cost in review, drift, and oversight that a rewrite maximizes. But none of that matters until you measure the codebase. Cover the money paths with unit tests, add end-to-end tests, run a technical audit, and check your end-of-life libraries. Those steps tell you which decision you have, they make AI safe to point at your code, and if the answer is a rewrite, the test suite they produce is the only thing that proves the new app behaves like the old one. Decide on evidence, not on the momentum of a bad sprint.

Bring Teamvoy your aging React Native app and we’ll run the test-and-audit steps, tell you honestly whether it’s an upgrade or a rewrite, and execute it with AI where it is safe and by hand where it is not, without stopping your release train.

FAQ