SaaS due diligence red flags: what to look for in a codebase

In short: when you buy, invest in or inherit a SaaS product, the red flags that matter most are rarely exotic. They are missing tenant isolation, secrets in the repository, one person holding the keys, no tested backups and releases that depend on manual steps. This list is for acquirers and investors who need to know what to look for and what each flag usually costs. It is based on audits of real production systems.

Red flags, ranked by how often they decide the outcome

1. Tenant isolation is not enforced

In a multi-tenant product, every query must be scoped to the right customer. In a garage-management SaaS I audited, a query that was missing its tenant-ID filter could have exposed one garage's certificates to another. The audit found and fixed 14 documented bugs, several of them serious cross-tenant leak risks. If isolation is a convention rather than an enforced layer, treat it as a critical finding. See multi-tenant architecture explained.

2. Secrets in the repository

An API key committed to a frontend environment file was the high-severity finding in one audit. Search the history, not just the current files; a key that was removed later is still compromised.

3. One person holds the keys

In one due diligence, a single contractor held the only credentials to the production database and the deployment pipeline and had not been paid in seven weeks. Check who owns the cloud account, the domain, the repository and the app-store accounts.

4. Weak access control on files and uploads

One audit found that a mislabelled GIF or SVG upload could trigger stored XSS. File upload is where many applications fail: check type validation, storage location and who can read what.

5. Sessions and tokens that cannot be revoked

A refresh token with no revocation path means a stolen token works forever. A review of a household-finance app found exactly this, plus a cross-household data gap through an unvalidated foreign key.

6. Backups that have never been restored

A backup is only a backup after you have restored from it. Ask for the date of the last successful restore test.

7. Releases depend on manual steps or one developer

If deployment is a series of manual commands that one person knows, every release is a risk. An automated pipeline that builds and deploys on each push, with health checks, is a strong positive signal.

8. A data model that cannot carry the next step

If the product needs a second country, a second tenant type or an API for partners and the schema fights it, the cost sits in the data model, not in features.

9. No tests where money or permissions are involved

Coverage percentage matters less than whether payments, permissions and migrations are tested.

10. Outdated dependencies with known vulnerabilities

Run the package manager's audit. A clean result, as on one backend I reviewed (zero vulnerabilities), is a good sign; hundreds of findings are a cost line.

How to price a red flag

For each finding, ask: what happens if nothing is done, and what does it cost to fix in developer-days? A flag without a number is not actionable. Rank findings by risk removed per day spent.

Green flags worth noting

• Documented architecture decisions and a clear owner for each module.
• Internal security reviews with dated, fixed findings.
• Automated deployments with health checks and rollback.
• Per-tenant configuration and numbering designed in, not bolted on.

Get it reviewed independently

The Delivery Risk Audit is built for this: ten working days, fixed price, a one-page risk matrix, the three weakest areas costed in developer-days, a 90-day plan and a live readout. I do not bid on remediation, so the findings are not a sales pitch. Start with the nine-area checklist and what a code audit checks.