Technical Red Flags in a SaaS Acquisition

A red flag in technology diligence is not simply something that is wrong. Every software company has problems. A red flag is a finding that changes what the buyer is willing to pay, how the deal is structured, or how much work the first year will take. This article walks through the technical red flags that tend to matter most in SaaS acquisitions, how to spot them, and how buyers usually respond.

Why SaaS is different

In a SaaS business the product, the hosting and the operations are all part of what the buyer is paying for. Revenue depends on the service staying up, staying secure and staying affordable to run. That means technical issues show up in places finance teams care about: gross margin, churn, the cost of growth, and the reliability of recurring revenue. A technical red flag in SaaS is often a financial red flag that has not been recognized yet.

Red flag 1: per-customer copies that have drifted apart

What it looks like: each customer, or each large customer, runs on its own copy of the application or database, deployed and upgraded separately, while sales describes the product as a single platform. Separate per-customer deployments can be a sound choice for isolation, data residency or regulated customers. The red flag is not single tenancy itself; it is unmanaged divergence between copies, manual upgrades, and serving costs that are not reflected in pricing.

How to spot it: ask how many production environments exist and how a release reaches all customers. Look at the infrastructure accounts and count databases. Ask how long it takes to onboard a new customer technically.

Why it matters: when copies are not managed through the same automated release process, upgrades slow down, security patches are harder to roll out, hosting costs grow with customer count rather than usage, and custom code may have crept into individual copies.

Typical response: model the real cost of serving customers and the effort to consolidate. If consolidation is required for the buyer's growth plan, it belongs in the integration budget and sometimes in price.

Red flag 2: hosting costs that do not match the margin story

What it looks like: gross margin presented in the model does not reconcile with cloud invoices, or hosting costs are rising faster than revenue.

How to spot it: request twelve months of invoices by service and compare them to revenue by month. Ask what the largest cost lines are and why. Check whether some costs sit in other accounts, on personal cards, or under a parent company.

Why it matters: hosting is part of cost of revenue. An unexplained trend means margin assumptions in the valuation may be wrong.

Typical response: adjust the model, and ask management for a credible plan to bend the curve. If costs are hidden elsewhere, that is a disclosure issue as well as a technical one.

Red flag 3: security claims that cannot be evidenced

What it looks like: the company has answered customer security questionnaires confidently, but cannot produce the policies, access reviews, test reports or logs behind the answers.

How to spot it: take three or four answers from a recent questionnaire and ask for the evidence behind each. Ask who has administrator access to production and code hosting, and when that list was last reviewed.

Why it matters: beyond the direct security risk, inaccurate questionnaire answers can create contractual exposure with customers who relied on them.

Typical response: remediation before or immediately after close, and specific representations about security practices and incidents. If an undisclosed incident surfaces, it may affect structure significantly.

Red flag 4: unclear ownership of the code

What it looks like: founders, early contractors or an outsourcing agency wrote significant parts of the product, and the paperwork assigning that work to the company is missing or incomplete. Or open source components are used in ways that conflict with their licenses.

How to spot it: list everyone who has committed to the main repositories and match them against employment and contractor agreements. Run or request a dependency license scan.

Why it matters: the buyer is acquiring the right to use and sell the software. Gaps here go to the core of the asset.

Typical response: cure before close by obtaining signed assignments where possible. Remaining gaps are usually addressed with specific indemnities, escrow or price.

Red flag 5: one person holds the system together

What it looks like: a single engineer, often a founder or long-tenured lead, is the only person who can deploy, debug or explain the most important parts of the system.

How to spot it: ask who was involved in the last five production incidents and the last five releases. Ask to see runbooks. Notice whose name comes up when anyone is asked "how does this work?"

Why it matters: if that person leaves, the buyer may be unable to operate or change the product safely.

Typical response: retention arrangements, earn-out design that rewards knowledge transfer, and a documentation and cross-training plan in the first 100 days.

Red flag 6: data handling that would not survive the buyer's standards

What it looks like: personal data appears in logs, analytics tools or test environments; retention is indefinite; there is no clear list of sub-processors; data residency commitments are not reflected in where data actually lives.

How to spot it: ask for a data inventory and a sub-processor list, then compare them against what you see in the architecture and vendor contracts. Ask how a customer deletion request is handled from start to finish.

Why it matters: privacy obligations follow the data into the buyer's organization. A target that is acceptable as a standalone company may fall short of the buyer's own obligations.

Typical response: budget for remediation to the buyer's standard and address known non-compliance in representations.

Red flag 7: reliability nobody has measured

What it looks like: no incident records, no uptime history, backups that have never been restored, and customer contracts with service-level commitments.

How to spot it: ask for the incident log and the last backup restore test. Read SLA terms in the largest customer contracts and ask whether credits have ever been paid.

Why it matters: the buyer cannot judge revenue quality without knowing how often the service fails its customers, and untested recovery is a continuity risk.

Typical response: early plan items for monitoring and recovery testing, and a closer look at churn and credits in the financial workstream.

Red flag 8: the roadmap depends on a rewrite

What it looks like: management's growth plan assumes a new platform, a major migration or a rebuilt core that has not started or is partway through.

How to spot it: ask what must be true technically for the next two years of the plan to happen. Ask how much of the rewrite exists today and who is working on it.

Why it matters: rewrites frequently take longer and cost more than planned, and the existing product still needs maintenance in the meantime.

Typical response: treat the rewrite as a project with its own budget and risk, not as an assumption. Where the seller's projections depend on it, earn-out milestones may be more appropriate than paying for it up front.

What a red flag is not

Old code is not automatically a red flag. Neither is a small team, a monolith, or an unfashionable language. These matter only when they change cost, risk or timing in a way the buyer has not priced. Good diligence separates findings that change the deal from findings that are simply interesting.

Next steps

If you are evaluating a SaaS target and want an independent technical assessment, see how we approach pre-acquisition due diligence, or use our software acquisition technology due diligence checklist to organize your own review.