Most side-project purchases are not really revenue acquisitions. They are purchases of code, a domain, an audience, a user base or a head start, and any revenue is incidental. Working out which of those you are buying changes the entire diligence exercise, and it is worth deciding explicitly before you start.
TL;DR: Side projects are usually bought for the code, audience or domain rather than for retained revenue. Here is how to tell which you are buying and what to check for each.
Side-project marketplace, very small, frequently pre-revenue. That shape determines what a buyer can expect to be given and what has to be requested, which is most of what changes between one acquisition channel and another.
Listings are typically short, describing the project, its stage, whatever traction exists and the builder's reason for selling. Revenue, where present, is usually small and recent. The most useful information is often about the technology and the user base rather than the financials.
Almost all financial diligence material, usually because there is not much to document. What matters more here and is equally often missing: the state of the code, the transferability of accounts and dependencies, whether users are active, and whether the domain or audience has any real standing.
If the revenue is small and young, you are buying an asset rather than a cash flow, and it should be valued that way. Decide which thesis you are underwriting and apply the matching diligence: for code, that is a technical review; for an audience, engagement data; for revenue, the retention analysis.
A user count is not a user base. Ask for active users on a stated definition — logged in within thirty days is a reasonable one — and treat registration totals as a vanity figure. This is the most common overstatement at this end of the market and it is not usually intended as one.
Side projects are built for one person's convenience. Unusual stacks, absent documentation, no tests and hard-coded configuration are normal rather than exceptional. Have someone read the code before you agree a price, since the cost of taking it over is the real cost of the purchase.
OAuth applications, app-store accounts, API keys with individual terms, free-tier services tied to a personal account: any of these can block a transfer outright. Check them against the provider's own terms rather than the seller's assurance.
In order, and stopping early if any step produces a blocker:
Getting a usable export is its own problem, and the request wording that works differs by billing platform. The export guides cover eighteen platforms with the exact wording to send and the status values that mislead on each. Once you have the file, the seller-claims pages give the arithmetic for each specific claim, and the 23-point checklist is the short version of the whole process.
SideProjectors: https://www.sideprojectors.com/
ChurnLens is not affiliated with, endorsed by or a partner of any marketplace or broker named on this page. Listing formats, disclosure practices and terms change; treat the descriptions here as a starting point and verify current specifics with the marketplace itself. Nothing here is investment, legal or tax advice.
Every check on this page can be run by hand in a spreadsheet, and if you have the time you should. If you would rather not: send us the target's subscription export and we run the full human-reviewed analysis — logo churn, revenue churn, customer concentration, annual-plan decay, zombie MRR and an A–F revenue-quality grade. The free Starter tier covers one CSV per month, which is enough to check a single deal.
See a sample report → · Get the free 23-point checklist →
First decide what you are actually buying — code, audience, domain, users or revenue — because that determines everything else. Then check what conveys, whether third-party dependencies can transfer at all, and whether the user or revenue figures mean what they appear to. A technical review before price agreement is usually the highest-value step.
Much less than active users, and the gap is usually large. Ask for actives on a stated definition, such as logged in within the last thirty days, and treat total registrations as a vanity figure. This is rarely intended as an overstatement; it is simply the number most builders have to hand.
Sometimes, and sometimes not at all. OAuth applications, app-store developer accounts, individually-termed API keys and free-tier services tied to a personal account can each block a transfer outright. Check each against the provider's own terms rather than relying on the seller's assurance, and do it before agreeing terms.