App acquisition due diligence: what to check before buying an app

Before buying an app, establish three things: the earnings are real, the demand is likely to survive the handover, and you can legally and technically operate what you buy. A convincing listing and a working download are starting points, not proof of a sound acquisition.

This guide gives you a practical evidence plan for evaluating a specific app. If you're still choosing between acquisition and development, start with buying an app vs building one. If you're preparing to sell, use the same checks to organize your records, then test your assumptions in the app valuation calculator.

TL;DR

This is an editorial checklist, not an audit of a particular app or individualized financial, tax, or legal advice. Bring in an accountant, a technical reviewer, and a transaction lawyer where the risks exceed your expertise. Acquire.com's buyer guidance also separates financial, technical, legal, operational, and commercial evidence rather than treating due diligence as a single dashboard check. Acquire.com buyer guide

Define what you are actually buying

Write down the app identifiers, platforms, legal seller, and assets included in the proposed deal. Establish whether the transaction covers selected assets or an ownership interest in a company; have counsel explain the consequences for your specific transaction. Don't assume the app listing includes the domain, source repository, backend, customer contracts, or rights to every design asset.

Ask why the owner is selling and what they do in a normal week. Compare that answer with release history, support tickets, contractor invoices, and incident records. An app described as passive may depend on an owner who fixes outages, refreshes ad creatives, and answers refund requests without recording those hours as an expense.

Create an asset register with four columns: asset, current owner, transfer method, and evidence of completion. Include store listings, code and build scripts, domains, cloud projects, databases, payment integrations, analytics, creative files, documentation, and vendor contracts. Mark exclusions explicitly. A shared account serving several apps may require separation work before closing.

Reconcile the financials before applying a multiple

As a working starting point, request monthly records for the last 12 months and a longer history if available. Use the full available history for a younger app, but don't present a few strong months as a verified annual track record. Compare the latest three months with the preceding three and, where possible, the same months a year earlier to separate recent deterioration from seasonality.

Start with the source records. Request appropriate read-only access or supervised exports from the store, payment processor, ad network, and accounting system. Use a controlled data room and redact unnecessary personal information. You don't need a seller's password or unrestricted customer data to start evaluating a listing.

Bank deposits, MRR, and accounting revenue answer different questions. An annual subscription can produce cash today while creating a service obligation for the coming year. Ask an accountant to reconcile the timing, revenue recognition, deferred obligations, and transaction cut-off. Don't count MRR and the associated store proceeds as separate income.

For a simple operating model, start with receipts after store and payment fees, refunds, chargebacks, and indirect taxes. Subtract the ongoing costs required to sustain those receipts. Don't deduct a commission twice because it appears both in the payout report and the expense spreadsheet.

Normalize earnings for the next owner

An add-back removes an expense from the historical cost base. It needs a documented reason: the expense was included, and it will not continue under the agreed operating plan. Recurring development, customer support, and acquisition spending don't become optional because the seller calls them discretionary.

If owner compensation is removed, include the cost of replacing the work that still needs doing. Avoid charging replacement labor twice when a retained contractor already covers it. Keep a bridge from reported profit to adjusted profit so a buyer can challenge each change.

Here is a hypothetical example using the same basis as our calculator:

At an assumed 3× annual profit multiple, that produces a $153,000 gross price. The multiple is illustrative, not a claim about current app sale prices. This operating-profit definition is not automatically the same as seller's discretionary earnings (SDE) or EBITDA; reconcile the definitions before using a comparable transaction.

Check whether customers and revenue will stay

Lifetime downloads say little about the users who remain active or pay now. Review active users, paid subscribers, and renewal cohorts by platform, country, plan, and acquisition source. Use consistent metric definitions and periods. A monthly subscriber churn figure cannot be compared directly with an annual plan's renewal rate.

Ask for cohorts that have had enough time to renew. A recent surge in annual subscriptions may look healthy before the first renewal is due. Check whether growth came from a price increase, a promotion, a paid campaign, store featuring, or stronger ongoing demand. Each has a different implication for the next year.

For subscription apps, examine trial-to-paid conversion, renewals, refund behavior, and access failures. For ad-supported apps, separate delivered impressions, effective CPM, and user activity. Revenue can fall because users leave, because ad rates fall, or both. The AdMob calculator can help model the arithmetic, but your assumptions should come from the app's own records.

Review the largest concentrations: one traffic source, country, platform, customer, or distribution partner. Work out what happens if the largest one weakens. An overall growth percentage can conceal shrinking organic traffic funded by increasing ad spend.

Evaluate market conditions in the app's actual niche

Build a dated comparison of three to five relevant competitors in the target countries. Record their core promise, pricing, recent updates, review complaints, and how users discover them. Include free substitutes and features built into the operating system. Ask what would make a customer keep paying for this particular app.

Treat third-party download and revenue estimates as directional evidence. They can help identify questions, but they do not verify a seller's accounts. Compare search-interest trends with the app's own store impressions, conversion rates, installs, and renewals. A category can attract attention while an individual app loses customers.

For paid growth, calculate acquisition cost and realized contribution over a defined cohort window, after relevant variable costs. Check how long cash is tied up before acquisition spend is recovered. A lifetime-value estimate is fragile when there isn't enough retention history to support it. Use the ROAS calculator for scenarios, while keeping revenue return distinct from profit.

Also examine buyer demand for businesses like this one. Where completed-sale information is available, compare transaction date, business size, monetization model, profit definition, and payment terms. Separate asking prices from actual consideration, and cash at closing from an earn-out that may never be paid. An old SaaS revenue multiple does not establish today's value for a small ad-supported mobile app.

Summarize the market evidence in a short investment memo: why demand should persist, what could reduce it, and which assumptions still need proof. Don't pay upfront for an untested redesign or a country expansion you would have to execute yourself.

Inspect the product, code, and operating burden

Have a reviewer build the app from the supplied repository and documented dependencies in an isolated environment. Verify that the repository corresponds to the live product, and check what is missing from the build and deployment process. Don't run unfamiliar acquisition code with access to production credentials.

Test the core journey on supported devices: onboarding, sign-in, purchase, restore, cancellation access, and account deletion where applicable. Review crash and incident history, backups and recovery, dependency maintenance, test coverage, and infrastructure bills. Our subscription launch checklist provides a starting test plan for purchase and entitlement behavior.

For an AI app, inspect the rights and terms for models, datasets, and generated assets, plus API spending at realistic usage. A profitable cohort with low usage may not represent the cost of serving engaged customers. Check service quotas, abuse controls, and what happens when a vendor is unavailable.

Turn findings into priced work: essential repairs, migration costs, ongoing maintenance, and optional improvements. Keep one-time remediation separate from recurring operating costs and agree how each affects the offer. A discount cannot compensate for an app you cannot lawfully operate.

Verify ownership and plan the transfer

Have counsel review ownership of the code, brand, designs, and content, including contractor assignments and third-party licenses. Identify disputes, security incidents, store enforcement history, contractual restrictions, and privacy obligations. Whether customer data or contracts can transfer depends on the transaction and applicable requirements; do not assume a database export establishes permission.

Apple requires an app to meet its transfer criteria and documents separate handling for features including auto-renewable subscriptions and Sign in with Apple. Check the app's actual integrations against that process before agreeing a closing sequence. A store transfer is not a complete backend migration. Apple app transfer overview

Google says payout, earnings, and bulk export reports do not transfer with the app. Obtain the needed historical records before handover. Its transfer guidance also identifies work for integrated services, so assign an owner to each dependency rather than assuming the store transfer moves everything. Google Play app transfers

Document who will transfer each asset, update integrations, rotate credentials, verify billing and access, and retain historical records. Agree how pre-transfer refunds, prepaid service obligations, and support requests will be handled. Avoid a plan that depends on permanently sharing the seller's personal developer account.

Use a valuation range, then test the downside

For an earnings-based scenario, the calculation is straightforward:

Gross price = normalized annual operating profit × annual profit multiple.

The judgment lies in the earnings and the multiple. A 3× annual multiple is equivalent to 36× average monthly profit when both use the same 12-month base. A seller quoting 36× monthly profit is not quoting 36× annual profit.

Use the app valuation calculator to enter your financials, choose low/base/high multiples, and see the asking price's implied multiple. It also estimates seller proceeds after entered selling costs and shows the effect of lower profit. It does not infer market rates from a few metrics or verify the seller's numbers.

Continuing the hypothetical $51,000 annual-profit example, a 25% profit reduction leaves $38,250. At the same assumed 3× multiple, gross value falls from $153,000 to $114,750. A buyer might also reduce the multiple if the decline exposes a deeper problem. Model both risks rather than assuming the multiple stays fixed.

For a buyer, add transaction fees, migration, urgent repairs, and working-capital needs to the headline purchase price. Evaluate cash flows after any financing and taxes with an adviser. A 3× profit multiple is not a guaranteed three-year payback: future profit, reinvestment, and your actual costs can change.

The AI rollups guide works through a hypothetical 20% buyer contribution, loan repayments, additional starting cash, and a downside case. Use that structure to separate purchase funding from the operating improvements you hope to make.

For a seller, distinguish the headline price from proceeds. In a hypothetical all-cash $153,000 sale, an assumed 5% selling fee and $3,000 of other closing costs leave $142,350 before taxes, debt, and other adjustments. Those cost assumptions are examples, not quoted marketplace fees. Holdbacks, financing, and contingent consideration require a separate schedule.

If profit is zero or negative, don't force an earnings multiple. Code, IP, distribution, or strategic fit may have value, but they need a different assessment. The calculator deliberately withholds a profit-based price in that case.

Make the final decision from an evidence register

Record each material claim alongside its evidence, reviewer, unresolved question, and effect on the deal. Use verified, unresolved, and failed as statuses. A folder full of PDFs is not the same as completed review.

Pause if the seller cannot substantiate material earnings, cannot show ownership of a critical asset, or cannot explain how the app will operate after transfer. Decide with your advisers whether an unresolved issue can be addressed through further evidence, a changed price or structure, or ending the process.

Before releasing funds, follow the agreed closing and escrow instructions and independently verify payment details. Confirm completion through the acceptance checks in the agreement. A successful store transfer alone does not prove the repository, backend, contracts, and customer access are ready for you to run.