How to Buy an Existing App: A Due-Diligence Checklist (2026)

Start with what you are actually buying

Most app deals are asset purchases. You are usually buying some or all of these, and the listing should say which:

• The store listing and app record: its reviews, ratings, ranking history and bundle ID or package name.
• The source code and build instructions, plus any design files.
• Backend and accounts: hosting, databases, analytics, push notifications, ad networks, subscription tools.
• Brand assets: domain, website, social accounts, support inbox.
• The users and subscriptions that come with the app.

Anything not listed is not included. Ask early, because a missing backend account or an unowned domain is far cheaper to discover before you agree a price.

1. Verify the revenue at the source

A number in a listing is a claim. The strength of the evidence behind it matters more than the number. From strongest to weakest:

1. Connected, live data. A RevenueCat Verified page, a Stripe connection or a TrustMRR profile shows figures pulled from the provider, which the seller cannot edit. On AppAcquire, listings with a connected source show live revenue, MRR and subscriber charts, and carry the Verified badge once ownership proof and a store link are in place.
2. Store reports. App Store Connect or Play Console financial reports, ideally shown on a screen share so you see them load rather than receiving screenshots.
3. Read-only access to the seller's dashboards during due diligence.
4. Typed figures or screenshots alone. Treat these as a starting point, never as proof.

Whatever the source, check these details:

• Is the figure revenue or proceeds? Apple and Google keep a share of every sale before the developer is paid.
• Do the last 12 months move steadily, or is one month carrying the average?
• How high are refunds and chargebacks, and are they rising?
• Is the revenue in one currency and one country, or spread out?

2. Confirm the seller owns the app

Ask the seller to prove control of the store account before you spend time on anything else. The developer name on the public store page should match the person or company you are dealing with, or they should explain the difference. Then ask for a live demonstration, such as a short screen share of the app inside App Store Connect or Play Console.

This matters for the transfer itself. On the App Store, only the membership Account Holder can start a transfer. On Google Play, the original account owner submits the request. If the person you are talking to is not that owner, the deal cannot complete without them. See the transfer guide for the full process.

3. Look past the headline number

Two apps with the same revenue can be very different purchases. These are the signals worth asking about:

Upkeep is easy to overlook. Google Play now only offers apps that target an older Android version to devices running that version or lower, so an app that has not kept up can quietly lose reach. Apple also removes apps that have not been updated for a long time and see very few downloads. A neglected app is not necessarily a bad buy, but you should price in the work to bring it up to date.

4. Check the code and the stack

• Can you build it? Ask for the repository, the build steps and a fresh checkout that compiles. Ideally the seller demonstrates it.
• Who owns each service? Firebase or Supabase projects, RevenueCat, analytics, push, email, ad accounts. Confirm each one can be transferred or that you can recreate it.
• Third-party licences. Look for open-source components with restrictive terms.
• Running costs. Hosting, databases, APIs and paid SDKs, per month.
• Key-person risk. If a contractor built and runs the app, find out whether they stay.
• Secrets. Plan to rotate every API key and credential once the handover is complete.

5. Work out a fair price

Small apps are usually priced as a multiple of annual profit or revenue. Flippa sales data for H1 2026 puts app businesses at about 2.6× annual profit on average, with the top quartile around 5.5×. Two tools help you sanity-check an asking price:

• The payback calculator turns a price and monthly profit into payback months and a return, including a downside case.
• The market data page shows what other sellers on AppAcquire are asking, by category and by revenue multiple.

Remember that an asking price is where a seller starts, not where a deal necessarily ends. Use verified numbers, not hopes, to negotiate.

6. Agree what is included, and how you pay

• A written list of assets: code, store account or app transfer, backend, domain, social accounts, support inbox.
• A support period after the sale, such as 30 days of answering questions.
• Payment through escrow, released only after you confirm you have full access and the app sits in your account.
• A simple asset purchase agreement. For anything beyond a small deal, have a lawyer read it.

Red flags that should slow you down

• The seller will not show revenue at the source or connect a provider.
• The store developer name does not match the seller and there is no explanation.
• Revenue that jumps just before the listing goes live.
• A vague or template description that says nothing about how the app makes money.
• Pressure to skip escrow or close quickly.
• Questions about the backend or accounts are met with silence.

The checklist

• Seller shown to control the store account (live demonstration).
• Twelve months of revenue seen at the source, refunds included.
• Proceeds versus gross revenue understood.
• Retention or churn reviewed by cohort.
• Traffic sources known: organic, paid, one-off.
• Concentration by country, platform and ad network checked.
• Recent reviews and ratings read.
• Last update date and current SDK or API target confirmed.
• Repository builds from a clean checkout.
• Every third-party account listed with an owner and a transfer plan.
• Running costs added up.
• Written inventory of what is included, escrow agreed, support period set.