SaaS due diligence: what to have ready before you talk to a buyer
Most founders meet due diligence for the first time in the middle of a sale process, when the request list arrives and everything has to be assembled at once. The work is rarely difficult. It is simply easier to do calmly, in advance, than under deadline.
This page describes what a buyer generally wants to understand about a SaaS or software company, and what it helps to have organized before the first serious conversation. It is written from the buyer's side, by a company that acquires software businesses and operates them afterwards.
This page is general guidance from a buyer's point of view. It is not legal, tax, accounting, or valuation advice, and RETIEB does not represent sellers.
What due diligence is actually for
Due diligence is not an audit and it is not a test to pass. A buyer is trying to answer one question: does the business behave the way it has been described, and what will it take to keep it running once the person who built it is no longer the only one who understands it.
That means most requests fall into three groups. What the company earns and how reliably. What the company owns and whether that ownership is clean. What the company depends on — people, contracts, vendors, and undocumented knowledge.
Preparation changes the tone of a conversation more than the contents of any single document. When answers arrive quickly and match each other, a buyer spends its attention on the business rather than on reconciling inconsistencies. Where a question touches legal, tax, or accounting interpretation, that is the point to involve your own advisers rather than improvise an answer.
What to have in order before talking to a buyer
The checklist below is general market guidance, not the policy of any particular buyer. Nothing in it is a requirement RETIEB imposes; it is a description of what buyers of small and mid-sized software companies commonly ask to see. Treat it as a reference to work through at your own pace, and ignore the categories that do not apply to your business.
Financial and revenue records
A buyer will usually want to understand how money actually moves through the business, and to see the same numbers told the same way twice.
- Profit and loss statements and balance sheets for the last several completed years, plus the current year to date
- Monthly recurring revenue history, with new, expansion, contraction, and churned revenue separated where your billing system allows
- A reconciliation between billing or payment-processor exports and the accounting records
- A current list of subscription plans, prices, discounts, and any legacy pricing still in force
- Cost of revenue detail: hosting, third-party APIs, payment fees, and support costs
- Outstanding debt, loans, grants, deferred revenue, and any personal expenses currently run through the company
- Tax filings and confirmation that filings and payments are current in every jurisdiction where the company registers
Customers, churn and concentration
Buyers often look beyond revenue size to understand revenue quality, and clean customer and retention data is much easier to organize before a process begins.
- An anonymized customer list with start date, plan, contract value, and status
- Retention and churn history over time, defined once and calculated consistently
- Revenue by customer, so that any material customer concentration is visible rather than implied
- Renewal dates for annual contracts, and whether renewals are automatic or negotiated
- How customers are acquired today, and which channels are paid, organic, referral, or partner-driven
- Support volume and common ticket themes, which often explain churn better than the churn number does
Contracts and ownership
It helps to have every agreement that could survive a change of ownership in one place, including the ones nobody has looked at in years.
- Formation documents, the current cap table, and any option, SAFE, note, or warrant outstanding
- Customer agreements, terms of service, and any negotiated enterprise contracts that differ from the standard terms
- Assignment and change-of-control clauses, which commonly create friction if they require customer or vendor consent
- Vendor and supplier agreements, including hosting, data providers, and critical third-party APIs
- Contractor and employment agreements, with confirmation that intellectual property assignment is in place for everyone who wrote code
- Any past or pending disputes, claims, or unresolved customer credits
Product, code and intellectual property
A buyer will usually want to know that the software can be handed over intact, and that everything in it can legitimately be transferred.
- Repository access history and a clear record of who has contributed code over the life of the product
- An inventory of open-source dependencies and their licences, with attention to any copyleft licence in shipped code
- Trademarks, domains, and registered intellectual property, together with the accounts that control them
- A current architecture overview: services, data stores, queues, scheduled jobs, and external integrations
- Build, test, and deployment process, including how a release reaches production today
- Known technical debt and any component that only one person understands well
- Design assets, brand files, and marketing site ownership, which are commonly held in someone's personal account
Security, privacy and infrastructure
Unresolved security, privacy, and infrastructure questions can create friction late in a process, especially when ownership, access, or data handling is unclear.
- An inventory of hosting, infrastructure, and SaaS accounts, with who holds the root credentials for each
- Access control practice: how accounts are provisioned, rotated, and removed when someone leaves
- Backup and restore arrangements, and the last time a restore was actually tested
- What personal data the product stores, where it is stored, and which sub-processors touch it
- Privacy policy, data processing agreements, and any regulatory regime your customers require you to meet
- Security incident history and how incidents were handled and communicated
Team and founder dependency
Founder and key-person dependency can materially affect how a buyer thinks about continuity after a transaction, and it is difficult to address convincingly at the last minute.
- Who does what today, including work founders do informally and would not list on an org chart
- Which parts of the operation only one person can perform, and what would happen if that person were unavailable
- Contractor arrangements, notice periods, and whether relationships are contractual or informal
- Key relationships — customers, partners, vendors — that currently run through a single individual
- Compensation arrangements, including any below-market founder salary that understates the true cost of running the business
- What the founders intend to do after a sale, described honestly rather than aspirationally
- Any knowledge that exists only in conversation and has never been written down
Operational documentation
The goal is that a competent operator could keep the business running from the written record alone.
- Runbooks for recurring operational work: releases, billing runs, onboarding, and incident response
- The support process, including tooling, response expectations, and escalation paths
- Onboarding and offboarding steps for customers and for staff
- A record of operating metrics as they are actually measured, with definitions attached
- The marketing and content operation: what is published, where, and by whom
- A list of recurring administrative obligations — renewals, filings, certifications — and their due dates
What belongs in a data room
A data room is simply one organized, access-controlled place where the materials above live, rather than a trail of attachments across an email thread. Buyers generally benefit from receiving materials this way, because it makes it obvious what exists, what is missing, and which version is current.
For many smaller software transactions, a structured shared folder with clear top-level categories and controlled access is sufficient. Larger or more regulated transactions often use a dedicated virtual data room, usually at the point where access logging and granular permissions genuinely matter. The choice of tool is yours; no particular product is necessary for a conversation to be productive.
Whatever you use, it helps to mirror the categories above, to name files so their period and version are obvious, to keep an index at the top level, and to redact personal data where the underlying question can be answered without it. Sequencing also matters: sensitive material such as full customer identities is commonly shared later in a process rather than at first contact, and your own advisers are the right people to help decide what is shared when.
Issues worth cleaning up before a sale process
Some issues are far cheaper to resolve before a process than during one. None of these is disqualifying on its own; each one commonly creates friction when it surfaces unexpectedly.
- Intellectual property written by a contractor with no assignment agreement in place
- Company assets — domains, analytics, app-store listings, ad accounts — held in personal accounts
- Personal expenses run through the company, which make the true cost base harder to read
- Metrics defined differently in different documents, so that two decks disagree about the same month
- Verbal customer commitments, credits, or discounts that appear nowhere in the contracts
- Open-source licences in shipped code that were never reviewed
- A material customer relationship that has never been documented beyond an email thread
- Operational knowledge that lives only with one person, with no written runbook behind it
Where any of these touches a legal, tax, or accounting question, that is a matter for your own advisers rather than something to resolve from a checklist.
What RETIEB publicly says about its own process
Everything above is general guidance. What follows is the only thing RETIEB says publicly about how it works, and it is deliberately short.
Every message reaches a human, and we reply in kind. If both sides want to continue, the route is a direct conversation, a thoughtful diligence, and clean terms — founder-friendly, never brokered, and respectful of what came before.
A conversation is not an offer, and RETIEB does not acquire every company it speaks with. Terms depend on the transaction.
Where to go next
If you are preparing a software or SaaS company for a sale, or simply want to understand how a direct buyer thinks before you decide anything, a conversation is a reasonable place to start.
Tell us about your companyYou can also read what RETIEB acquires and why.
Still deciding which route to take? Compare brokers, marketplaces, and selling directly.