App Takeover Audit: What We Check Before Taking Over

Before we take over an app, we check four things in this order: who owns the accounts and keys, whether the app can be built and released today, the state of the code, and how it handles crashes and user data. The result: a written verdict per part — keep, fix, refactor or rewrite — and a fixed price per module.

Why the order matters

An inherited app usually comes with a long list of worries. Most of them can wait. The ones that cannot are the ones that stop you shipping: an account you do not control, a signing key nobody can find, a build that no longer compiles with today's tools. So we look at the ability to release first and code quality second — even though code quality is what everyone asks about.

1. Access and ownership

The first question is not "is the code good?" but "can you publish without asking anyone?"

If anything here is in someone else's name, moving it to yours comes before any code change. How that works on each store is in our guide to transferring an app to your own developer account.

2. Can it be built and released today?

An app that nobody has touched for a while often cannot ship an update even if nothing in it is broken. Both stores raise their requirements every year: Google Play requires updates to target a recent Android API level (target API requirements), and Apple requires new builds to be made with a recent Xcode and SDK (upcoming requirements).

So we try the boring things first:

1. A clean build from the repository, on a fresh machine, for both platforms. 2. The toolchain gap — how far the build tools have fallen behind: Flutter and Dart versions, Gradle and the Android build tools, Xcode, and the minimum OS versions the app supports. 3. Dependencies: packages that are abandoned, pinned to old versions, or block an upgrade of everything else. 4. The release path: is there an automated build pipeline (CI), does it run, and does it publish from accounts you control. 5. Store status: rejected builds, policy warnings, declarations that are out of date.

This step often decides the first module of work on its own: getting the app back to a state where a routine update can be built and published.

3. The code itself

Here we read rather than count. Line counts and test coverage percentages say little about whether an app is safe to change. We look for:

• Structure — whether screens, business logic and data access are separated well enough that a change in one place stays in one place.
• State management — how data moves through the app: one consistent approach, or several layered on top of each other.
• The risky places — payments, authentication, sync, anything that touches money or personal data.
• Platform code — native modules, plugins and workarounds that will need attention on the next OS release.
• Tests that matter — not the coverage figure, but whether the flows that make money are protected.

If the app is native rather than Flutter, this step also maps which parts form the core we would rebuild first when moving it to Flutter — your native app keeps shipping while that happens.

4. Crashes, data and privacy

The fourth area is what happens in production:

• Crash reports: the top crashes, how many users they hit, and whether they have been there for months.
• Analytics: what is tracked, whether it is still being collected, and who can see it.
• Personal data: what the app stores on the phone and on the server, how it is protected, and whether the store privacy declarations still match what the app does.
• Third-party SDKs: every SDK in the app is a promise you make to your users on someone else's behalf.

What you get at the end

A written verdict, not a sales call. For each part of the app it says keep, fix, refactor or rewrite, with the reason — how each of those is decided is in fix, refactor or rewrite an inherited app. Then the work is split into modules, each with a fixed price agreed before we write any code. Keeping what works is the default; "rewrite everything" is what a new team says before it has read the code.

How to read a takeover proposal from anyone

Whoever you hire, a good proposal for an inherited app has these traits:

1. It starts with access, not with features. 2. It names specific problems found in your code, not general best practice. 3. It separates keep, fix, refactor and rewrite instead of pricing a rebuild by default. 4. It says how you will see progress — test builds you can install beat status reports. 5. It keeps the code, the accounts and the pipeline in your name from day one.

If a proposal fails the first or the last point, the problems that brought you here are likely to come back.

How we work on takeovers

DriveCode builds iOS & Android apps, Flutter-first. This is the process behind our app takeover service: access in your name first, a written verdict second, then a fixed price per module and regular releases again. If the old developer has simply vanished, start with what to secure first.

Questions people ask

Do you need access to everything before you can say anything? To give a verdict, yes — the repository and read access to the store accounts and backend. Before that we can tell you what we would look at and in which order.

Will you tell us to rewrite the app? Only the parts that are cheaper to replace than to fix, and the verdict says why. Every part gets one of four answers — keep, fix, refactor or rewrite — and keeping what works is the default.

Our app is native. Can you still take it over? Yes. We secure access, review the app and plan the move to Flutter, core first: the Flutter core ships as an MVP while the native app keeps shipping; the rest follows in regular updates, most-used first.

Do we need tests before you start? No. Missing tests are a finding, not a blocker; we add them where the risk is.