SaaS Technical Due Diligence: What Buyers Must Check Before Closing a Deal

In a conventional acquisition, financial diligence tests the earnings and legal diligence tests the contracts. In a SaaS acquisition, a large share of the value sits in something neither of those workstreams can see directly: software that has to keep running, keep being maintained and keep belonging to the business after the founder steps back. Technical diligence is the workstream that looks inside it.

The aim is not to grade the engineering. It is to answer four practical questions. Can the business keep operating at the same quality after closing? Does it own what it says it owns? What will it cost to keep the product healthy and growing? And do the numbers the buyer is paying for come out of real systems? Each of those questions maps to a price, a protection in the agreement or a plan for the first hundred days.

The workstreams overlap in two places that matter. IP ownership is both a legal and a technical question, and SaaS metrics are both a financial and a technical one. Those are the places where gaps are most often missed, because each team assumes the other has covered them.

It works with individual buyers, private equity, roll-up aggregators, venture investors, self-funded searchers and search funds. Confirm current scope, pricing and turnaround for your deal before you commit.

Reviewers rarely need to read every line. They sample the parts of the codebase that carry the most risk: billing, authentication, the data model and the features that customers pay for. What they are looking for is whether the code can be understood, changed and released by someone who did not write it.

• Structure and consistencyIs the codebase organised in a way a new engineer could navigate? Are there clear boundaries between the product, the billing logic and the integrations?
• Automated testsDo tests exist for the paths that matter most, and do they actually run before releases? Coverage as a percentage matters less than whether billing and permissions are covered.
• Release processHow does code get from a developer to production? A repeatable, automated release with the ability to roll back is a sign of a healthy product. A manual process that depends on one person is a risk.
• Technical debtWhich shortcuts has the team knowingly taken, and what would it cost to fix them? A maintained backlog of known debt is a better sign than none being mentioned.
• DocumentationAre there architecture notes, set-up instructions, runbooks for common incidents and descriptions of the data model? A new owner needs these on day one.
• Framework and language currencyIs the stack still supported by its maintainers? An end-of-life framework turns into a security and hiring problem.

Putting technical debt in dollars

Debt becomes a negotiating point when it is converted into an estimate. Ask the reviewer to group findings into three bands: items to fix before closing, items to fix in the first year, and items that are acceptable to carry. For the first band, ask for an engineering time estimate. A buyer can then ask the seller to fix the items, reduce the price by the estimated cost, or hold back part of the consideration until they are fixed.

Infrastructure diligence answers three questions: is the product running on infrastructure the business controls, does the cost scale sensibly with customers, and can the business recover from failure. Ask for read-only access to the cloud console rather than screenshots, so the reviewer can see what is actually deployed.

• Account ownershipWhose name is the cloud account, domain registrar and source-control organisation registered in? Assets held in a founder's personal account need to be transferred at closing and listed in the agreement.
• Architecture and single points of failureIs there one database server, one region or one person with the keys? Redundancy does not have to be elaborate, but the risks should be known.
• Cost per customerCompare hosting and third-party usage costs with revenue. A product whose infrastructure cost grows faster than revenue has a margin problem that does not show up in last year's accounts.
• Scalability evidenceLook at load history, slow-query logs and any capacity incidents. Ask what happens if usage doubles, and what the seller would change first.
• Backups and recoveryAsk when backups were last restored in a test, and how long recovery took. A backup that has never been restored is a hope rather than a control.
• Uptime and incidentsRequest the incident history and any customer-facing status page records, and compare them with what customers were told.
• Monitoring and alertingWho is told when something breaks at night? If the answer is a single founder's phone, that is a transition risk to plan for.

Infrastructure cost belongs in the valuation model as well as the diligence report. Gross margin on a SaaS business is only meaningful if hosting, third-party services and support costs are allocated properly, so ask the financial reviewer to compare the cloud bill with the cost of revenue line in the accounts.

A buyer of a SaaS business takes on the customer data the product holds and the obligations that come with it. A breach that happened before closing can become the new owner's problem, and customers increasingly ask vendors for evidence of security controls before they renew. Security diligence is therefore partly about risk and partly about protecting the revenue.

• Access controlWho has access to production systems and customer data, how is access granted and removed, and is multi-factor authentication enforced? Shared admin credentials are a common finding in small teams.
• Vulnerability managementHas the product been tested against the common web vulnerability classes, such as those catalogued in the OWASP Top 10? Ask for the latest penetration test and what was done about the findings.
• Data handlingWhere is customer data stored, is it encrypted at rest and in transit, and is production data copied to developer machines or test environments?
• Privacy lawWhich jurisdictions do customers sit in? Check data processing agreements, sub-processor lists, retention and deletion practices, and how data subject requests are handled under laws such as the GDPR.
• CertificationsDoes the business hold or work towards frameworks such as SOC 2 or ISO 27001? Where customers contractually require them, check the certificate is current and covers the whole product.
• Incident historyAsk for all security incidents in the last few years, how they were handled, and whether any customers or regulators were notified.
• Payment dataIf the business stores or handles card data, confirm how it stays within payment card rules. Many products avoid this by passing card data directly to a payment processor, which is worth confirming.

Every SaaS product stands on other people's work: open-source libraries, cloud services, payment processors and external APIs. The diligence question is whether those dependencies are licensed in a way that allows the product to be sold as a commercial service, and whether any single dependency could disrupt the business if it changed.

Open-source licences

Open-source licences fall broadly into two groups. Permissive licences, such as MIT, BSD and Apache 2.0, generally allow commercial use with attribution. Copyleft licences, such as the GPL family, can require that software built on them be released under the same terms in some circumstances. The AGPL is the one most relevant to SaaS because it extends those obligations to software that users access over a network. A reviewer will run a licence scan across the dependency tree and flag anything that needs a legal view.

API and platform risk

Products that live inside another platform's ecosystem, such as marketplaces, plug-ins and integrations, depend on that platform's rules. Read the developer terms, check how often they have changed and look for any history of the platform restricting access. This is a commercial risk as much as a technical one, and it often belongs in the purchase price or the earnout structure rather than a fix list.

Ownership is the question that cannot be fixed by good engineering. A product built by employees under written agreements is usually straightforward. A product built partly by freelancers, agencies, former co-founders or contributors with no written assignment can leave gaps in who actually holds the rights.

• Employee agreementsDo they assign work product to the company? Rules on who owns employee-created work differ by jurisdiction, so confirm with counsel.
• Contractor and agency workFor every contractor who contributed code, look for a signed agreement that assigns the rights to the company. Ask the repository history who has committed code and match the names to agreements.
• Founder and former co-founder contributionsCode written before the company was formed, or by someone who has left, needs a written assignment into the company.
• Trademarks, domains and accountsCheck registrations are in the company's name and are transferable. Domain names, app store accounts and social handles are often held personally.
• Customer data and outputsConfirm customer contracts say who owns the data and any outputs the product generates, and that the business is allowed to use anonymised data in the way it currently does.
• Open-source contributionsCheck whether the company has contributed code to open-source projects, and whether it has retained the rights it expects.

Key-person dependency

Ask a simple question of the repository: who has written most of the code in the last twelve months, and what happens if they leave? A bus factor of one is common in small SaaS businesses and is not disqualifying, but it should be reflected in the transition plan. Typical responses include a paid handover period, a retention arrangement for the key engineer, documentation as a closing deliverable, and a deferred or earned-out portion of the price tied to a smooth transition.

If the seller is the main developer, the transition plan is the integration plan. Agree how long the seller will remain involved, what they will hand over in what order, and what happens if they decide to stop. For structuring options, see locked box vs completion accounts and seller financing and seller note protection.

SaaS businesses are priced on recurring metrics, so a small error in how MRR or churn is calculated can move the price by a multiple of that error. The seller's dashboard is usually produced by a script, a spreadsheet or a third-party analytics tool, each with its own definitions. Technical diligence rebuilds the numbers from the systems that generate them and checks they agree.

Definitions matter as much as arithmetic. ARR, MRR and churn are not defined by accounting standards, so the first step is to write down how the seller calculates each one and to apply the same definition across the whole history. Changing definitions mid-history is a red flag; documenting them is not. For a detailed treatment of what counts, see ARR vs revenue: what software buyers actually count.

The three-way reconciliation

1. 1.Billing system to payment processor: do the invoices and subscriptions in billing match the charges that were actually collected?
2. 2.Payment processor to bank: do payouts match deposits, after fees, refunds and chargebacks?
3. 3.Bank to accounts: do the deposits tie to recognised revenue and deferred revenue in the books?

If all three tie out, the reported metrics are on firm ground. If one does not, the gap is the finding. It may have an innocent explanation, such as timing differences, but it needs to be explained before the metric is used to set the price. Pair this work with a financial review such as the quality of earnings readiness assessment, and use the SaaS valuation calculator to see how a corrected figure changes the range.

• A metrics dashboard nobody can reproduceIf the seller cannot show the query or export behind a number, treat the number as unverified.
• Backups that have never been restoredThe control exists on paper only.
• One cloud, billing or repository account in a personal nameA transfer problem at closing and a sign that company assets are mixed with personal ones.
• Core modules written by a contractor with no assignmentAn ownership gap that is slow and sometimes impossible to fix after closing.
• A feature that depends on a single third-party APIThe provider's terms can change the product's economics.
• Customers paying outside the billing systemManual invoices and side agreements make MRR harder to verify and renewal terms harder to track.
• Unusually high revenue per support ticket or unusually low ticket volumeCheck whether support is being handled in a way that hides product problems, such as by the founder directly.
• Growth that comes from a discount or a promotion that has endedThe trailing metrics may overstate the run rate.
• A long list of exceptions to the standard contractCustom terms for large customers can affect renewal, termination and price.
• Security questionnaires customers have sent but the business has not answeredA sign that enterprise sales will stall after closing.

A good review is scoped before it starts, uses read-only access, and ends with findings ranked by what they do to price and risk. The sequence below suits most SaaS acquisitions; adjust the depth to the size of the deal.

• 1. Agree scope and questionsWrite down the questions that would change your offer. Decide which areas need a specialist and which can rely on the seller's own documentation.
• 2. Request accessAsk for read-only access to the repository, cloud console, billing system, payment processor, product analytics and the P&L. Where the seller is cautious, agree a staged release of information, with the most sensitive material only after exclusivity or a signed letter of intent. See the due diligence checklist for a full request list.
• 3. Rebuild the metricsDo the reconciliation first. If the numbers do not hold, it changes the scope of everything else.
• 4. Inspect the productReview the code samples, infrastructure, security reports and dependency scans. Interview the lead engineer to understand how the product is maintained in practice.
• 5. Write findings in bandsGroup findings into must fix before closing, plan for in the first year, and acceptable. Add an estimated cost to each of the first two.
• 6. Turn findings into termsDecide which findings change the price, which move into the agreement as warranties or indemnities, which become closing conditions and which become a first-hundred-days plan.

Sellers can make this faster and cheaper by preparing a technical data room in advance. Acquiry's technical due diligence readiness page is written for sellers and sets out how to do that. Buyers can use the same list to see what a well-prepared seller should be able to produce.

Strategic acquirers often use their own engineering leaders for the technical review. Private equity firms, search funds, family offices and individual buyers frequently do not have that capability in-house and engage an independent reviewer instead. An independent reviewer works for the buyer only and writes the findings in terms that a non-engineer can use to set a price.

One provider in this space is WebAcquisition (opens in a new tab), which describes itself as a buy-side due diligence firm for online and small-business acquisitions. According to its website, the firm provides financial, marketing and technical due diligence alongside deal sourcing and advisory support, and works with individual buyers, private equity, roll-up aggregators, venture investors, self-funded searchers and search funds. It says its founder, Mushfiq Sarker, has been active in business acquisitions since 2008, has completed more than 200 exits and has carried out due diligence on more than 1,000 businesses.

For software, the firm publishes a dedicated SaaS business due diligence (opens in a new tab) service. Its page describes a written PDF report built on a 24-point analysis, covering market, product, marketing, valuation, P&L verification, website and domain history, monetisation and traffic. To carry out the review it asks the buyer to arrange access to the business URL, the back end as both a customer and an admin or owner, an analytics platform, payment processors or revenue analytics tools such as Stripe or ChartMogul, and the seller's P&L. It states that reports are delivered within seven business days after access is provided, and that it can review a business before an offer or letter of intent has been made.

As with any provider, buyers should confirm current scope, pricing and turnaround directly, and check that the review covers the areas that matter most for the specific deal. WebAcquisition's SaaS service is described around smaller online software businesses and traffic-led metrics, so a buyer of a larger or enterprise-facing product may want to confirm how deeply it covers the code, infrastructure and security areas set out above, or pair it with a specialist engineering review.

Technical diligence is most useful when it informs a clear view of what the business is worth to a particular buyer. Strategic buyers weigh the product against their own roadmap, financial buyers weigh the retained revenue and margin, and individual buyers weigh what they can operate themselves. The same findings can produce different answers for each.

• To understand which kinds of buyer pay for which characteristics, see software company buyers.
• For the full buyer-side picture on SaaS deals, including valuation and structure, see the SaaS acquisitions guide.
• To find software businesses that match a defined thesis, including businesses that are not for sale, see how Acquiry runs buy-side acquisition origination.
• To compare independent providers, calculators and other resources by stage of the deal, use the Buyer's Toolkit.