SaaS Due Diligence Checklist for Sellers: What Buyers Will Ask For
A practical SaaS seller diligence checklist covering financials, customers, product, code, legal, support, handoff, and red flags that kill small deals.
Direct Answer
Buyers will ask for proof that your SaaS revenue is real, durable, transferable, and not hiding a support or technical mess. For a small SaaS, diligence usually covers monthly revenue, profit, customers, churn, product scope, codebase, infrastructure, legal ownership, support load, and handoff. You do not need a massive data room to start. You need clean enough materials that a buyer can verify the core claims without guessing.
Diligence kills small deals when the story changes: MRR is unclear, churn is worse than expected, support is heavier than described, or the product cannot be handed over without the founder.
Who This Is For
Why Small SaaS Deals Fail During Diligence
Small SaaS deals often fail because the buyer's confidence drops after the first conversation. The seller described a clean recurring software product, but the documents reveal a harder handoff.
The buyer's lens is risk compression. They are asking: after I buy this, what hidden obligation lands on me?
Common confidence drops:
- MRR cannot be reconciled to billing.
- The founder excludes real costs when describing profit.
- Churn is higher than the headline suggests.
- The code deploy process lives in the founder's memory.
- Customer issues are more frequent than expected.
- Key assets are in personal accounts.
Financial Diligence
Financial diligence is not complicated, but it has to be clean. A buyer wants to see how much money comes in, what it costs to run the SaaS, and whether the profit number is honest.
Prepare:
- Monthly revenue for the last 12 to 24 months if available.
- Current MRR and ARR.
- Payment processor exports.
- Monthly expenses: hosting, tools, contractors, payment fees, support, and required services.
- Owner add-backs only if they are real and explainable.
- Refunds, credits, failed payments, and past-due accounts.
At this size, an honest $600 monthly profit can be more useful than an inflated $900 number that falls apart in review.
Revenue and Customer Diligence
Customer diligence shows whether the revenue is durable.
Prepare a simple customer table:
- Customer name or anonymized ID.
- Start date.
- Current plan.
- Current MRR.
- Last payment date.
- Cancellation status if relevant.
- Notes for any unusually large customer.
If one customer represents a large share of MRR, say so early. Customer concentration is not always fatal, but hiding it is.
Product and Code Diligence
A buyer does not need every engineering detail in the first call. They do need to know whether the product can be run by someone else.
Prepare:
- Repository location and access plan.
- Framework and language.
- Local setup notes.
- Deploy process.
- Test coverage if any.
- Known bugs and technical debt.
- Third-party services and integrations.
- Cron jobs, queues, email sending, webhooks, and background tasks.
If the code is old but understandable, say that. If deploys are fragile, say that too. Buyers can handle known problems better than surprise problems.
Infrastructure Diligence
Infrastructure diligence checks whether the app can keep running after close.
Prepare:
- Hosting provider.
- Database provider.
- Domain registrar and DNS.
- Email provider.
- Error monitoring and logs.
- Backups and restore process.
- Admin accounts and transfer constraints.
- Environment variables list without sharing secrets in an unsafe way.
The buyer wants to know what must be transferred, what must be recreated, and what could break during migration.
Legal and IP Diligence
Legal diligence for a tiny SaaS is usually about ownership and permission. Do you own or control the product, domain, brand, code, and customer contracts you are selling?
Prepare:
- Company ownership details if the SaaS is held in an entity.
- Domain ownership.
- Terms of service and privacy policy.
- Contractor agreements if contractors wrote meaningful code.
- Open source dependency notes if relevant.
- Customer contracts or standard terms.
- Any disputes, refund issues, chargebacks, or unusual promises.
Do not invent legal certainty. If something is unclear, disclose it and let the buyer decide how to handle it.
Support and Operations Diligence
Support is where tiny SaaS deals often become real. A buyer wants to know whether the product will interrupt every week.
Prepare:
- Ticket volume by month.
- Common support issues.
- Average support hours per week.
- Customer onboarding steps.
- Refund or cancellation process.
- Admin tasks required to keep the product running.
- A simple handoff plan.
Hypothetical example: a $1,100 MRR SaaS with ten support tickets per month may still sell if those tickets are simple password resets. The same ticket volume is more concerning if each ticket requires manual database fixes.
Minimum Data Room Checklist
| Folder | Include | Purpose |
|---|---|---|
| Financials | Revenue by month, expenses, payment exports, profit estimate. | Proves the economics. |
| Customers | Customer list, plan, MRR, start date, churn notes. | Shows durability and concentration. |
| Product | Feature summary, roadmap, known issues, screenshots if helpful. | Explains what customers are buying. |
| Code | Repo access plan, stack, setup, deploy notes, integrations. | Reduces technical handoff risk. |
| Legal | Terms, privacy policy, contractor agreements, domain ownership. | Confirms what is being transferred. |
| Support | Ticket volume, common issues, admin tasks. | Shows operating burden. |
| Handoff | Transfer checklist, accounts, timeline, founder availability. | Makes closing practical. |
If you are still early and wondering whether a buyer would take the SaaS seriously, start with how to sell a SaaS around $1K MRR.
Common Red Flags
| Red flag | Why buyers care | What to do |
|---|---|---|
| MRR does not match billing | The buyer cannot trust the headline number. | Reconcile revenue before sharing a valuation ask. |
| High customer concentration | One churn event can change the asset. | Name it early and explain the relationship. |
| Founder-only support | The buyer may be buying a job. | Document support workflows and reduce manual steps. |
| Undocumented deploys | Technical transfer can fail. | Write repeatable setup and deploy notes. |
| Personal-account dependencies | Some assets may not transfer cleanly. | List constraints and migrate what is practical. |
| Unwritten customer promises | The buyer may inherit obligations they did not price. | Document promises and disclose unusual terms. |
What can kill the deal is not asking hard questions. What kills the deal is finding a different business than the one described.
What to Do Next
Start with the smallest useful data room. Then decide whether to improve before selling or talk to buyers now. If valuation is your open question, read small SaaS valuation multiples explained. If channel choice is the issue, read where to sell your SaaS business.
- Best fit: SaaS doing roughly $500 to $5,000 MRR.
- Useful even if you are only curious about options.
- No customer contact or disclosure without permission.
FAQ
What will buyers ask for first?
Usually MRR, revenue history, expenses, customer count, churn, support load, and a basic technical overview. Deeper documents come after the buyer sees fit.
Do I need a full data room before talking to buyers?
No. You need enough to avoid wasting time. A clean summary and a minimum data room are usually enough for an early serious conversation.
What if I do not have clean books?
Clean what you can. Export billing data, list expenses, and explain gaps. Vague numbers are a bigger problem than imperfect records.
Will buyers inspect the code?
Often, yes. They may not review every line, but they will want to understand stack, deploy process, integrations, and technical debt.
Can diligence lower the price?
Yes. If the buyer discovers higher risk than expected, they may lower the offer or walk away. Good preparation reduces that chance but does not guarantee an outcome.