Small SaaS products are often attractive because one person built and operated them cheaply. That simplicity can also hide concentration risk: one personal GitHub account, one undocumented server, one domain registered years ago under an old email address.
For a small acquisition, the review can stay compact. It still has to answer one blunt question: what must keep working on the first morning after the seller steps away? The small-SaaS acquisition guide shows how this inspection fits with transfer and post-closing work.
Map the production system
Ask the seller to walk from a code change to a paying customer. Where is the code stored? How is it deployed? Which database receives customer data? Which services handle authentication, email and payments? Where are errors reported?
Write the answers as a dependency map. Mark which services handle production and which are experiments or abandoned integrations. A long software list is worthless when nobody knows which entries still affect customers.
Inspect the accounts behind the services
For every critical service, record the organisation, current owner, administrators, billing owner and recovery method. Look for resources that live inside the seller's personal account instead of a business-owned organisation.
Check whether the provider supports ownership transfer. If it does not, estimate the work of migrating to a buyer-controlled account. That effort belongs in the acquisition decision and transition schedule. Domain ownership deserves separate attention: ICANN’s registrant guidance explains the responsibilities attached to the registered name holder, not merely the person who can edit a DNS record.
Read the repository as operational evidence
The repository can reveal dependencies the seller forgets to mention. Review package manifests, imports, workflow files, deployment configuration and environment-variable names. Do not request secret values through email or shared documents.
Pay attention to old deployment workflows, hard-coded endpoints, personal email addresses and services mentioned in code but absent from the seller's inventory.
Test repeatable operations
Ask for evidence that a second person can deploy the application from a clean environment. Confirm backups exist and that somebody has tested restoration. Review what happens when email, payments or the database provider has an outage.
If the product has scheduled tasks, background jobs or webhooks, identify where they run and how failures are noticed. These quiet processes are easy to miss because the homepage can remain online while important work silently stops.
Separate defects from transfer risk
A code defect may be inconvenient but visible. Transfer risk is different: it prevents the buyer from controlling or repairing the system. A missing test suite may reduce confidence; an inaccessible production database can stop the acquisition entirely.
Prioritise findings that affect ownership, customer data, revenue, deployment and recovery. Give every serious finding an owner, a required action and a deadline before or after closing.
Finish with evidence
The seller's explanation gives you the map. Account access and operating tests tell you whether the map is accurate. Check both before the inspection period closes. Ask specifically whether the buyer will receive ownership or only collaborator access; source code alone does not establish control.
You will probably find technical weaknesses. The point is to find the expensive ones while there is still time to change the price, the handover plan or the decision to buy. Once the deal proceeds, move to the small-SaaS handover checklist rather than repeating due diligence as if no ownership changes were under way.