What diligence does a pre-revenue asset need?
The short answer
Pre-revenue diligence checks usage, code and rights rather than earnings. Confirm monthly actives on a defined event in a live analytics session, read the dependency list, check who owns the code and content, and establish that every account, domain and store listing can transfer to you cleanly.
What diligence does a pre-revenue asset need?
Less financial work and considerably more technical and legal work than a revenue-generating deal. There are no processor statements to reconcile and no churn to model, so the checking moves to the three things you are actually paying for: the user base, the thing that was built, and the right to own it. A week is usually enough at $10,000 to $50,000, and skipping it is how buyers end up owning code they cannot deploy.
Scale the effort to the price. Two days on a $12,000 app, a week on a $35,000 tool, and in both cases finish the checks before the money moves rather than after.
What replaces revenue verification?
Usage evidence, taken live rather than from exports. Sit on a screen-share with the analytics property open, agree a definition of an active user before you look at the number, and then look at it. A defined event such as a completed core action is the only figure worth quoting; logins, installs and registered accounts all overstate the base and all three get used in listings.
Ask for twenty-four months rather than twelve. You are looking for the shape of the curve, not the height of it, and a base that has been flat for a year is worth more than one twice the size that has been falling since a launch spike.
How do you check the user or traffic numbers?
Work through this in order, and stop when something does not reconcile.
- Agree the definition of an active user or a session in writing, then read it back from the live dashboard.
- Check two independent sources. Analytics against search console, or store console installs against backend account creation.
- Look at geography and device mix. Traffic concentrated in territories with no commercial value is worth a fraction of the headline.
- Look for the shape of real people. Session duration, returning visitor share, and a weekday pattern.
- Ask for the top twenty pages or the top twenty accounts by activity, and check they are not all one thing.
- Email a sample of users yourself, with the seller's agreement, and see whether anyone replies.
The last step is the one buyers skip and the one that settles it. Ten replies from people who describe the product accurately tells you more than any dashboard.
What do you check in the code and the stack?
Whether you can deploy it from a clean machine without the seller in the room. That is the whole test, and it is worth paying a developer two hours to try. A codebase nobody but the original author can run is worth its replacement cost minus the cost of the rewrite, which is often close to zero.
Then read the dependency list for things that will bite later: an SDK on a deprecated version, a service with a free tier that ends at your expected volume, a model or API whose terms prohibit the use you intend, and anything on a licence that restricts commercial use. Check when the platform requirements next change, because a native app facing a mandatory rebuild is carrying a bill you will pay.
What do you check about ownership and rights?
Who wrote it, who owns it now, and whether anything in it belongs to someone else. Pre-revenue assets are more likely than mature businesses to carry loose ends: a contractor with no assignment in place, design bought under a personal licence, content written by freelancers on unclear terms, or an image library used outside its permitted scope. Get written confirmation for each, and a proper assignment of everything in the sale.
The domain matters more than people think at this price. Confirm the registrant, the registration date, that it is not locked into a personal account tied to an employer, and that it has no history you would rather not inherit.
What kills a deal at this size?
These are the findings that should end it rather than reprice it.
| Finding | Why it ends the deal |
|---|---|
| Actives cannot be reproduced live | The base is the asset. If it cannot be shown, it does not exist |
| Code will not run without the seller | You are buying a rewrite at full price |
| No account system, no emails, no way to reach users | Nothing to monetise and nothing to migrate |
| Contractor-built with no assignment | You would not own what you paid for |
| Traffic collapsed after a platform update and never recovered | You are buying the wrong side of a curve |
| Seller will not do a live screen-share | The most reliable signal there is |
Repricing findings are different and common: a falling base, thin documentation, an expiring integration, a founder who does support personally. Those are negotiating positions rather than exits.
What does a proportionate process look like?
Five working days, structured. Day one is usage evidence on a live call. Day two is the code, run by a developer who is not you.
Day three is rights, domains and third-party terms. Day four is the transfer plan, covering every account, repository, store listing and DNS record that has to move, with a named owner for each.
Day five is the offer, written down, with the findings attached and the price explained. Transfers complete through Escrow.com, with the buyer bearing that fee at 2.4% between $5,000 and $50,000, so include it in the budget rather than discovering it at the end. The habits you build here are the same ones a six-figure deal needs, at a scale where mistakes are affordable.
Related: due-diligence-for-a-100k-deal, how-to-take-over-hosting-domains-and-payments, replacement-cost, traffic-quality
See what a business at this level is listed at.
Everything on sale between $50,000 and $150,000, on the same fields.