Before buying a SaaS business, verify that someone other than the seller can deploy it, recover its data and operate the customer workflows that matter. Ask for demonstrations with a known code version and a controlled environment. Keep a separate list of what could only be described, what was checked and what still needs evidence.
A product demo shows that the current service runs. An operating test shows what happens after the people, accounts or infrastructure behind it change. The gap between those two things is where a buyer can inherit unexpected work.
Trace one paying customer’s workflow
Choose a representative flow that connects product activity to an obligation the new owner must keep. That might be signing up a workspace, processing a scheduled report and delivering it to users. Map the code, data and external services involved. Ask who can inspect each part and who can repair it if it fails.
Then ask for an exception. What happens when the scheduled report fails, a subscription renewal is delayed or a customer loses access? A normal demonstration can omit an operator who silently corrects problems every day. Watch how the team detects the failure and what information they use to respond.
Keep the review evidence proportionate to the transaction and respect the agreed access boundaries. A walkthrough, read-only evidence and a controlled exercise can answer different questions. Use sanitised records or test accounts when customer data is unnecessary.
Ask for a deployment from a clean starting point
Pick a known version and observe a build and deployment using documented steps. Record the repository, dependencies, build environment, configuration, schema changes and resulting application version. A successful deployment from the seller’s laptop may rely on a local file, private package or key that the buyer will never receive.
Ask for a realistic staging environment where the exercise can run without affecting customers. Have a person who did not write the deployment steps follow them. When they need help, write down what was missing. Distinguish something that can be added to a runbook from a dependency that requires account ownership or vendor action.
Confirm the deployed version can perform the chosen customer workflow. A green build and a login screen are useful evidence. They leave open whether background jobs, file storage, billing events or email will work with the proposed configuration.
Restore the parts that make the product usable
Ask for a restore into a safe environment. Check what point in time the data came from, how long the exercise took and whether the application can use it. A database restore may need uploaded files, compatible code and configuration before a customer can complete a task.
For an illustrative reporting product, verify that a restored customer can access a sample report and that a worker can produce a new one. Test with outbound delivery disabled or routed to test recipients. An isolated exercise gives the buyer evidence about recovery without sending messages or changes to real customers.
Separate the assets from the dependencies
| Area | Evidence to request |
|---|---|
| Code and release | Repositories, package access, build pipeline and a reproducible release from a named version. |
| Accounts and vendors | Who owns the domain, hosting, email, monitoring and integration accounts, and how access would transfer. |
| Recovery | A recent restore result, scope of what it covered and a repeatable process. |
| Operations | A real support workflow, incident history where available and the manual steps that still rely on the seller. |
Mark each item as verified, described or unresolved. For anything material that could not be tested before signing, identify what evidence would resolve it and who would need to provide it. Coordinate questions about rights, contracts and transfer terms with the people advising on the transaction. The technical review can explain why a dependency matters and how it could be tested.
Finish with a handover plan that describes the first release, the first recovery exercise and the person responsible for responding to an incident. If those actions depend on the seller, make the dependency explicit and describe how the new team would become independent.
Frequently asked questions
Is access to the source repository enough?
It is one piece of evidence. Also verify how the software builds, deploys, obtains its configuration and connects to the services it needs.
Should we test the production backup directly?
Run an authorised restore in an isolated environment with the agreed data protections. Verify the result there before relying on the backup as evidence of recovery.
What if the seller cannot allow a full test before signing?
Ask for narrower evidence such as an observed staging deployment or a redacted restore record. Record any limitations and make the unresolved technical questions visible to the buyer.
How is this different from a code quality review?
A code quality review explains risks inside the codebase. Acquisition diligence also asks whether the buyer will have the people, access, data and processes to operate the product.