Micro-SaaS acquisition checklist: what to request before making an offer

The first seller conversation should establish whether the opportunity deserves deeper work. Ask for the reported revenue period, paying-customer count, recurring operating expenses, recent customer losses and a list of assets included in the sale. State what you hope to verify and accept sensible redaction at this stage.

Keep a worksheet with five columns: claim, evidence requested, period covered, what you observed and what remains unresolved. A screenshot without a period or definition is incomplete evidence. Do not replace an unanswered question with a zero in your financial model.

Request six to twelve months of subscription and payment records where available. Separate recurring subscriptions from one-time purchases, trials and refunds. Reconcile what the billing system reports with the cash actually received and explain differences such as payout timing.

Use Stripe’s subscription analytics definitions as a reference if the business uses Stripe, while checking the seller’s own configuration. Compare opening and closing recurring revenue with new business and customer losses. Look at both customer counts and amounts so a single large account does not disappear inside an average.

• What period does the advertised monthly figure describe?
• Which customers pay repeatedly, and which payments are one-off?
• How much revenue depends on the largest customer and the largest acquisition channel?
• What changed after recent cancellations, refunds or pricing changes?

Collect recurring service bills, usage-based API costs, contractor payments, refunds and acquisition spending. Ask the seller to distinguish operating expenses from personal choices, while documenting any cost you would still need to incur. Record whether quoted profit includes owner labour.

Build a separate buyer scenario for work you cannot do yourself. Estimate the actual tasks, obtain relevant quotes if needed, and test lower revenue or higher infrastructure usage. Avoid presenting your scenario as the seller’s historical performance.

Ask a suitably skilled reviewer to follow the deployment instructions, inspect dependencies, check the backup and restore process, and identify secrets that must be rotated. Review how production incidents are handled and whether the seller is the only person who understands a critical component.

GitHub documents ownership transfers and their implications for repository access. Treat that as one technical step. Separately document the domain, hosting, database, email service, analytics, payment setup and external integrations. For each dependency, identify an owner and the concrete handover action.

Write down what should work after transfer: production deployment, customer login, billing events, emails, scheduled jobs and a test restore. Agree how the seller will help if one of those checks fails and which work is excluded from the handover. Confirm account and contract transfer requirements with the relevant provider and adviser.

Maintain a decision log with three possible outcomes for each unresolved issue: obtain more evidence, price a documented repair, or stop the process. The worksheet should help you make that decision, rather than provide a score that encourages you to ignore a missing answer.

1. 1List assets and dependencies with their current owners.
2. 2Identify the proposed transfer or migration method for each.
3. 3Assign an acceptance check, owner and target date.
4. 4Record unresolved commercial and technical questions before making a commitment.