Buying a Micro-SaaS: A Due-Diligence Guide Beyond the Multiple

Reconcile revenue to real customers

Start with a consistent period and compare billing records, payment-processor reports, bank receipts, refunds and accounting records. Revenue recognized over time differs from cash collected upfront. Annual subscriptions can create a large receipt while leaving months of service obligations. Trials, discounts, paused accounts, failed payments and one-off services may be included in a seller's headline metric. The buyer should understand each definition and reconcile the customer-level records to totals. Access should be authorized and privacy-conscious; investigating a business does not justify copying unnecessary personal data or exposing credentials.

Customer concentration changes the risk. A product with hundreds of accounts may still depend on a few large customers for most receipts. Check contracts, renewal dates and whether relationships are tied personally to the seller. Churn should be defined by customer and revenue, with a period and cohort. Expansion from one large account can conceal losses elsewhere. A short history or recent promotion can make the trend unstable. The question is not whether a dashboard shows a positive number, but whether the underlying customers, terms and behavior support the claimed recurring economics.

Earnings need a replacement-cost view

Seller-adjusted earnings often remove expenses described as discretionary or personal. Some adjustments may be reasonable, while others represent work the buyer will still need to perform. The owner's development, support, sales and administration should be recorded over a representative period. If a buyer lacks those skills, replacement labor may cost more than the seller's explicit expenses suggest. A business can remain attractive after that adjustment, but the comparison should be made before agreeing to a price. An unpaid founder's work does not disappear when ownership changes.

Include infrastructure, tools, payment fees, taxes, insurance and expected maintenance as relevant to the business. Promotional hosting credits can expire; an unusually low contractor rate may not continue; a deprecated dependency can require substantial work. Historical profit is evidence about the past under the seller's arrangements. It is not a guaranteed forecast under the buyer's staffing and operating conditions. A normalized model should state which costs continue, which change and which are uncertain. Professional financial, legal and tax review can address questions that a general acquisition checklist cannot resolve.

Worked example: normalize the cash flow

Imagine an illustrative product collecting $8,000 a month from subscriptions. Hosting, software and payment charges cost $1,500, while contractor support costs $500. The listing describes $6,000 in monthly owner earnings. The seller also spends 60 hours on development and support. If the buyer values replacement work at an illustrative $50 an hour, another $3,000 is needed, leaving $3,000 before additional expenses, taxes and acquisition financing. That does not determine the correct purchase price. It shows why the listing's earnings and the buyer's expected economic return are different quantities.

The buyer then models a decline in receipts, higher hosting costs and a required security improvement. They also identify annual prepayments already collected by the seller that create future service duties. The agreement and cash-transfer arrangements need to address those obligations appropriately. A business may still fit the buyer's capabilities, particularly if they can improve delivery efficiently. But the decision should not assume that every dollar in the seller's adjusted figure becomes passive income. The model must be able to survive ordinary operating work before any proposed growth initiative is credited with value.

Inspect the product as an operating system

A code review should address architecture, dependencies, build reproducibility, tests, documentation and the difficulty of making common changes. A working demonstration does not establish that a new owner can deploy safely or recover from failure. Identify hosting accounts, domains, certificates, email services, scheduled jobs and external APIs. Check whether the accounts and contracts can transfer and what consent is required. A product can depend on a personal account or nontransferable license that was invisible in the financial summary. Ownership of source code alone may not deliver an operable business.

Security and privacy deserve independent attention. Review access controls, secret handling, backups, logging, patching and incident history in proportion to the product's data and risk. The NIST Secure Software Development Framework offers a useful structure for software practices; FTC business guidance explains why reasonable data-security practices matter. Neither source certifies a particular acquisition. Evidence should include actual configurations, authorized tests and restoration exercises. A seller's statement that no breach is known differs from proof that the system has no vulnerabilities or that historic data handling met every applicable obligation.

Worked example: test the handover

Suppose an illustrative buyer receives a repository and deployment guide for a scheduling product. In an approved test environment, the buyer attempts to build and run it without the seller's personal accounts. The exercise reveals that a background task uses an undocumented API key and that customer reminders depend on a domain controlled by the seller's unrelated business. A backup file exists, but restoration has not been tested. These findings are operational dependencies, not merely untidy documentation. They affect whether the buyer can deliver the service after closing.

The parties establish a transition plan: replace or properly transfer credentials, document scheduled jobs, separate the domain arrangements and demonstrate restoration with suitable test data. They define acceptance evidence and an appropriate support period, with advisers handling the contractual terms. If a critical dependency cannot be resolved, the buyer can revise the transaction or decline. The exercise does not guarantee that every issue has been found. It establishes a more credible basis for operation than a screen recording of the seller using the product in an environment the buyer cannot reproduce.

Rights and promises travel with the product

Verify ownership and permitted use of code, designs, datasets, content and trademarks. Contractors may have created important components, and open-source dependencies can carry obligations. Customer contracts may limit assignment, require notices or promise service levels. Privacy statements, retention practices and processing agreements can create further responsibilities. The appropriate review depends on jurisdiction and the transaction structure. Do not assume that a marketplace listing or a transfer of assets resolves every right. The buyer needs clarity about what is being acquired and what must happen for the transfer to be effective.

Growth claims should face separate scrutiny. Search traffic may depend on a few pages, platform access may change and advertising results may reflect a short favorable period. Verify data through authorized read-only access where possible, preserving definitions and dates. A plan to raise prices or cross-sell should be a scenario, not part of guaranteed base earnings. Ask what evidence supports demand and what implementation would cost. A buyer's enthusiasm can make an uncertain improvement look inevitable, especially when it is needed to justify the purchase price. The existing business should be understood before the hoped-for business is valued.

Closing is the beginning of a transition. Inventory every transferred asset, account and responsibility, with owners and verification steps. Avoid abrupt changes that jeopardize customers while the buyer is still learning the system. Establish monitoring, a support channel and a process for unresolved issues. Preserve appropriate records without retaining access the seller no longer needs. A small acquisition may lack a large integration team, making a clear handover even more valuable. The goal is continuity first, followed by measured improvements based on observed behavior and a stable operating environment.

A good micro-SaaS acquisition review follows money to customers and software to the systems that keep it running. Normalize labor, inspect dependencies, verify rights and test the handover. Use valuation methods only after those facts are understood, with suitable professional advice for the transaction. No multiple guarantees a good purchase, and no checklist eliminates uncertainty. The useful outcome is a clear view of what the buyer would own, what they must provide and how much evidence supports the expected return. That is the foundation for an informed decision rather than a passive-income story.

Sources

• FTC Start with Security business guide
• NIST SP 800-218 Secure Software Development Framework