App due diligence checklist: what buyers check before buying your app

Due diligence sounds heavy, but for most small apps it’s a focused check that the numbers are real and nothing is about to break. This is the list I work through when I review an app. Use it to prepare before you talk to any buyer: an organized folder saves days and makes your numbers easier to trust.

How do you prove your app’s revenue?

With exports from the source systems, not a spreadsheet you typed yourself. Buyers want to see:

• App Store Connect Sales and Trends and Payments and Financial Reports for the last 12–24 months.
• For subscription apps, the RevenueCat (or similar) overview: MRR, active subscriptions, trial conversion, renewals, churn and refunds. The subscription side of a sale is covered in selling a subscription app.
• Bank statements or payout records that match the proceeds, useful for larger deals.
• Any other revenue: ads, web purchases, sponsorships.

How do buyers check costs and profit?

They rebuild your monthly profit from every cost the app has, because the price is a multiple of that profit.

• Ad spend by channel (Apple Search Ads, Meta, TikTok, Google) with the matching installs (see selling an app that runs on paid ads).
• Servers, APIs, AI/LLM costs, software tools, contractors and support. For AI apps, API cost by month is the first thing buyers look at: how to sell an AI wrapper app.
• A simple monthly profit-and-loss table.

What a buyer finds here moves the multiple directly: how much is my app worth explains which findings push it up or down. For a quick range before you talk to anyone, try the app valuation calculator.

What traffic and user data do buyers want?

Where your downloads come from, and whether users stay. Specifically:

• App Analytics: impressions, product page views, downloads, and source types (App Store search, browse, web referral, app referral).
• Top keywords you rank for and top countries.
• Retention and active users, if you track them.

What do buyers check in the code and product?

Whether the app can run without you, and whether anything is about to break.

• Tech stack, minimum OS version, and how builds and releases are done.
• Third-party SDKs and services, and who owns each account.
• Crash rate and known bugs.
• Anything that depends on you personally, such as a server on your own machine or a personal API key.
• Buyers usually look at the code itself only after an offer is agreed, or under NDA.

What App Store history and legal checks come up?

Past problems with the store, and proof that you own what you’re selling.

• Past rejections, warnings or removals, and why they happened.
• Reviews and ratings history. Incentivized or bought reviews are a deal-breaker for most buyers.
• Ownership of the name, logo, domain and any trademarks.
• Licenses for fonts, images, sounds and third-party code.
• Privacy policy and how user data is stored.
• Whether the app meets the transfer rules. Apple’s criteria (nothing in review, TestFlight off, no duplicate product IDs) are listed in my App Store app transfer guide.

How do you share data safely?

Under an NDA, by screen-share or screenshots, and never with your Apple Account password.

• Sign an NDA first if you’re sharing detailed numbers.
• Prefer screen-shares and screenshots to logins. If a buyer needs direct access, give the most limited access your tools allow, and remove it afterwards.
• Never share your Apple Account password or your developer account itself.

Which red flags kill app deals?

Numbers that don’t match, and problems that surface late.

• Numbers that don’t match between sources.
• A sudden spike right before the sale, usually paid ads that are about to stop.
• Undisclosed problems found late: App Review warnings, a key SDK being shut down, a legal dispute.
• Revenue that depends on the founder personally, such as client work or a personal audience.

Disclose these early. A known problem gets priced in; a hidden one ends the deal. Once due diligence is done, the next step is payment: see app sale escrow.