A code audit for the app you already have.

You get a written document that names what's wrong with the app, puts the problems in the order they're likely to cost you money, and attaches an effort estimate to each one. That last part is what separates an audit from a tool report. A static analysis run will hand you four hundred warnings sorted by a severity label, and not one of them tells you whether the app can survive the next operating system release.

The audit is built around a decision rather than around a codebase. Almost everyone who asks for one is choosing between four options: keep patching the app they have, rebuild it, hand it to somebody new, or stop spending on it entirely. Organising the findings around that choice means the report arrives with a recommendation attached, instead of a neutral catalogue that leaves you exactly where you started with a longer vocabulary.

It covers the architecture and how much of it is still holding up, the dependencies and how far behind they've drifted, the release process and whether anybody can actually ship, and the store presence including what your reviews are saying that your analytics never mention. Where crash reporting exists, the real failure data goes in as well, because the crashes users are hitting this week outrank anything an engineer finds unattractive about the code.

The plan that follows is sequenced rather than listed, so the first week removes whatever is blocking a release and the remaining weeks work down from there. A report nobody can act on is just a slower way of staying stuck, which is why the plan names the specific first fix instead of recommending a general direction and wishing you luck with it.

It needs read access to the repository, a viewer role in App Store Connect and Play Console, and whatever crash reporting the app already has wired up. That combination covers most of what matters, and none of it involves handing over administrator rights or transferring ownership of anything.

The repository is the obvious one and tells you less on its own than people assume. What reveals the most is whether an engineer who has never opened the project can clone it and produce a signed build on a clean machine. Plenty of inherited apps fail that on the first afternoon, because the build quietly depends on a certificate in a departed developer's keychain or on a configuration file that never made it into version control. Discovering that is a result rather than a delay, since nothing else about the app can be verified until it's solved.

Store access matters because a good share of the risk lives there rather than in the code. The review history shows whether releases have been getting rejected and for what reasons. The account itself shows who genuinely owns the app, which occasionally turns out to be an agency rather than the person paying for the audit. Crash reporting, whether that's Firebase Crashlytics, Sentry, the Xcode Organizer or Android vitals inside Play Console, supplies the failure data that sets the order of the fix list.

When source access isn't available yet, which is normal while a handover is still being negotiated, the audit runs on what can be reached from outside the codebase: the store listing and its update history, the public reviews, how the shipped app behaves on real devices, and the libraries the binary is carrying. That version costs less and answers fewer questions, and it's usually enough to decide whether the full assessment is worth buying at all.

A code audit is the wrong purchase when you already know what's broken. A team that can name its three worst crashes and point at the release that introduced them doesn't need a written diagnosis of the obvious, and buying one delays the fix by a week. That situation calls for mobile app stabilization instead, where the same money buys engineering rather than analysis.

An ownership problem also outranks a quality problem. If the store account sits with an agency you've stopped paying, or the signing certificates live in a mailbox nobody can open any more, the state of the code barely matters because you can't ship a fix to a single user regardless of how good it is. Sorting that out through an app takeover comes first, and the review that matters there is about accounts and access rather than architecture.

Some questions an audit simply can't answer honestly, and saying so is more useful than selling around them. It won't tell you what a rebuild will cost to the dollar, because that depends on scope decisions you haven't made yet. It won't predict whether Apple or Google will approve your next submission, since both run their own review on their own schedule, and any firm promising you an approval date is guessing in a confident voice. It also can't tell you whether your users will prefer the result, which is a research question rather than an engineering one.

What the audit does settle is whether the app you already have is worth continuing with, and that's the question most people are really paying to resolve. Everything else in the report exists to support that answer, which is why it ends with a recommendation and a first month of work rather than with a summary of how the reviewer felt about the codebase.