SaaS Due Diligence Checklist: Code, Customers and Contracts
Everything to check before buying a software business, grouped into revenue, customers, product and code, infrastructure, legal and data, operations and transfer.
Buying a software business means buying code, customers, infrastructure and promises, all at once. SaaS due diligence is how you check each of them before you pay: that the recurring revenue is real, customers will stay, the code can be maintained, the data is handled lawfully and everything can actually be transferred. Done well, it turns a risky purchase into a calculated one.
This checklist groups the work into seven areas, with the documents to request and the questions to ask in each. It suits micro SaaS products and larger software businesses alike. For the overall buying process, see how to buy a SaaS business.
Key takeaways
- Recalculate revenue, churn and refunds from raw payment data, ideally through read-only access.
- Check customer concentration, contracts and cohorts, not just totals.
- Have the code and infrastructure reviewed by someone you trust, under a confidentiality agreement.
- Review security, data protection and legal documents, including licences and IP ownership.
- Map every account and service to a transfer method before you sign.
The seven areas
SaaS due diligence covers seven areas. They overlap, and findings in one often explain another: rising churn may trace back to a product problem, a cost spike to an infrastructure decision. Work through all seven, even if the first ones look perfect. Each section below lists the items to request, followed by what to look for.
1. Revenue and churn
- Monthly recurring revenue for 12+ months, split into new, expansion, contraction and churn.
- Customer churn and revenue churn recalculated from raw data.
- Cohort analysis by sign-up month.
- Refunds, chargebacks and failed payments.
- Annual plans and how much revenue has been paid in advance.
- Payouts matched to bank records.
Revenue is where most problems surface, so it comes first. Look for consistency between the listing, the payment processor and the bank, and for patterns: does churn spike after price changes, promotions or product releases? Annual plans paid in advance need special attention, because some of that cash covers months you will serve after the sale. Ask for read-only access to the payment processor; Stripe, for example, offers restricted API keys limited to read access. Our guides to SaaS churn rate and MRR vs ARR explain the calculations.
2. Customers
- Revenue share of the top 5 and top 10 customers.
- Any custom contracts, discounts, service levels or promised features.
- Customer types, sizes and countries.
- Acquisition channels and cost to acquire a customer.
- Support tickets and common complaints.
Customer checks show how durable the revenue is. Many small customers with similar needs is usually healthier than a few large ones with special terms. Read any custom contracts carefully: promised features, uptime commitments or discounts become your obligations. If one customer pays a large share, find out whether their contract allows them to leave after a change of owner.
3. Product and code
- Code repository access for a reviewer, under a confidentiality agreement.
- Code quality: readability, tests, documentation.
- Dependencies: versions, known vulnerabilities, end-of-life libraries.
- Deployment process and how long a release takes.
- Technical debt the seller knows about.
- Product roadmap and promised features.
The code review tells you what owning the product will really involve. Clean, tested code with current dependencies can be maintained by one developer; tangled code on outdated frameworks may need months of work before you can add anything new. Ask the seller to walk your reviewer through the architecture and a typical release. Our guide to SaaS technical due diligence walks through the code review in depth.
4. Infrastructure
- Hosting providers, regions and monthly costs.
- Databases, storage and backups, with a tested restore.
- Monitoring, uptime history and incident records.
- Third-party services and APIs, and who owns each account.
- Scaling: how costs change as customers grow.
Infrastructure checks often reveal costs the profit figure doesn’t show yet, such as services on free tiers that will need paid plans as usage grows, or backups that have never been tested. Ask for a test restore from backup during due diligence; it’s the only way to know backups work.
5. Security and data protection
- Who has access to production systems, and how access is controlled.
- Two-factor authentication on critical accounts.
- Past security incidents and how they were handled.
- How customer data is stored, processed and deleted.
- Privacy policy and data processing terms.
- Compliance with data protection rules that apply, such as the GDPR for EU customers.
Widely used references such as the OWASP Top 10 list the most common web application security risks; a reviewer can use it as a starting point for checking the product.
Security and data protection carry legal as well as practical risk. If customer data has been exposed in the past, find out what happened, who was told and what changed afterwards. Make sure you understand which personal data the product holds and where it’s stored, because you’ll be responsible for it after the sale.
6. Legal and intellectual property
- Terms of service and whether they allow a change of owner.
- Assignments of IP from founders, employees and contractors.
- Open-source licences and how they’re used.
- Trademarks and domain ownership.
- Platform agreements (app stores, APIs, marketplaces).
- Any disputes, claims or regulatory issues.
Legal checks confirm that what you’re buying is really the seller’s to sell. Code written by contractors without a written assignment may still belong to them; open-source components may come with conditions; terms of service may need updating when the owner changes. See legal due diligence for the full list of documents.
7. Operations
- Hours per week the business takes, and who does what.
- Support process, response times and tools.
- Contractors and staff who’ll stay, and their terms.
- Documentation of recurring tasks.
- Vendor contracts and renewal dates.
Operations decide what your week will look like after the sale. A product that “runs itself” usually has someone quietly answering support tickets, renewing certificates and fixing small bugs. Ask for a typical week, written down task by task, and check it against support and deployment records. Our guide to operational due diligence explains how to assess workload.
Organising the documents
A shared folder, often called a data room, keeps SaaS due diligence orderly. Create one sub-folder for each of the seven areas and ask the seller to place each document there, with a short index listing what’s included and what’s still to come. Keep a log of questions and answers in the same place. When the deal closes, the data room becomes a useful reference for running the business.
Questions to ask the founder
- What would you fix first if you were keeping the product?
- Which customers are most at risk of leaving, and why?
- What breaks most often, and how long does it take to fix?
- Which tasks do only you know how to do?
- Which services, keys or accounts are tied to you personally?
- Have you ever had a security incident or data request from a customer or authority?
- Are there promises to customers that aren’t written in contracts?
Honest, specific answers to these questions often save more time than any single document in the data room.
Turning findings into the price
SaaS due diligence rarely ends with a simple yes or no. More often it produces a list of findings, each with a cost or a risk. Turn each into one of four outcomes: a price adjustment (for a known cost, such as a framework upgrade), a condition of closing (such as signing a missing IP assignment), a deal structure (such as part of the price paid later if a large customer stays), or an accepted risk you note and plan for. Discussing findings this way keeps negotiations factual and fair to both sides.
When to bring in advisers
For small products, a trusted developer and careful reading may be enough. As deals grow, consider a lawyer for contracts and IP, an accountant for revenue recognition and tax, and a security specialist for products holding sensitive data. Advisers cost money, but a missed problem in a software business can cost far more.
A sensible order of work
Start with the numbers: they’re the fastest to check and the most common reason a deal fails. If revenue and churn hold up, move on to customers, then code, then legal and data, and finish with a detailed transfer plan. Each stage either confirms the price or gives you specific reasons to adjust it.
How long each area takes
For a small software business, a realistic plan looks like this: two or three days for revenue and customers once read-only access is set up; three to five days for a code and infrastructure review; a few days for legal and data documents; and a day or two to map the transfer. Areas can overlap, and the seller’s responsiveness matters more than anything else. Agree a timetable at the start, including when the seller will provide each item, so both sides know when a decision can be made.
Mapping the transfer
Before signing, list every account and service and how it moves:
- Code: GitHub’s documentation explains that repositories can be transferred to a new owner, keeping issues and history.
- Payments: Stripe’s support says to contact them first when a business is sold; see transferring Stripe subscriptions.
- Cloud, email, monitoring and other services: transfer, invite or recreate, one by one.
- Domain and DNS: see the domain transfer process.
- App stores: each has its own transfer criteria.
A worked example
The details below are made up to show the method.
A buyer is considering an invoicing tool with $12,000 of monthly recurring revenue. Revenue checks pass: the read-only data matches the listing, and revenue churn averages 2.2% a month. Customer checks reveal that one agency pays 14% of revenue on a custom annual contract with a clause allowing cancellation on a change of control.
The code review finds tidy code but an outdated framework version that will need upgrading within a year. Legal review shows a contractor who built the payment module never signed an IP assignment. The buyer adjusts the offer for the upgrade cost and the concentration risk, and makes the contractor assignment a condition of closing. The seller obtains the assignment and contacts the agency, which confirms it will stay. The deal closes on terms both sides understand.
After closing
The due diligence work keeps paying off after the purchase. Use the findings list as your first 90-day plan: rotate every credential and API key, fix the security items, start the upgrades you priced in, and contact the largest customers to introduce yourself. Keep the data room as a reference, and update the documentation as you learn how the product really runs.
Red flags
- Revenue figures that don’t match the payment processor.
- Churn the seller can’t explain.
- Code the seller won’t allow anyone to review.
- Missing IP assignments from contractors.
- Security incidents that were never investigated.
- Critical services in the founder’s personal accounts with no transfer plan.
Our guide to micro SaaS for sale lists more warning signs specific to small products.
Ready to find your next asset?
Browse listings with verified numbers, ask sellers your questions before you offer, and agree every step in a free Deal Room.
Frequently asked questions
How long does SaaS due diligence take?
For a small product, often one to three weeks. Larger businesses with more customers, staff and contracts take longer.
Do I need a developer to review the code?
If you don’t code yourself, yes. A trusted developer can spot problems that would be expensive to discover later, such as outdated frameworks, fragile deployments or security gaps.
What documents should I ask for?
Read-only payment data, a customer list with revenue, contracts, code access, infrastructure details, security records, legal documents and IP assignments.
What’s the most common problem found?
Numbers that don’t match the raw data, followed by concentration in a few customers and missing paperwork for code ownership.
Should I sign a confidentiality agreement?
Yes. Sellers reasonably expect one before sharing code, customer lists and financial data, and it protects both sides if the deal doesn’t go ahead. Agree it before the detailed review starts.
Can I skip SaaS due diligence on a very small product?
You can scale it down, but don’t skip it. Even for a small product, check revenue in the raw data, review the code and confirm every account can be transferred.
