Technical due diligence for a small SaaS should answer a narrower and more useful question than “is the code good?” It should establish whether the product can continue to serve customers, protect data and change safely when the seller is no longer the only person who knows how to operate it.
That cannot be proved by a repository alone. A buyer is taking on a system made of source history, build and deployment authority, production configuration, databases, provider accounts, customer promises, licenses, invoices and operating knowledge. The job is to reconcile those surfaces against the deal thesis and make every material unknown visible before the transaction team decides how to treat it.
Use three evidence states throughout the review:
- VERIFIED — the claim was compared with an authoritative record, controlled test or observed system state;
- NOT VERIFIED — the claim may be true, but relevant evidence has not been produced or checked;
- UNAVAILABLE — the evidence cannot be obtained within the agreed scope or access window, and the decision impact is recorded.
Download the Small-SaaS Technical Evidence Memo template before opening the data room. Keep links to controlled evidence in the memo; never paste passwords, tokens, raw customer data or full proprietary source into it.
The asset is not just the code. The evidence boundary includes every system and person required to keep the business promise after close.
Before reviewing the target: protect the evidence and the product
Technical diligence does not authorize a buyer or reviewer to test anything they can reach. Agree the access and handling rules first:
- Define authority and scope. Name the buyer decision owner, seller technical owner, reviewer and systems in scope. Record whether access is read-only, screen-shared, isolated or seller-operated.
- Use least privilege and a controlled evidence room. Repository history, contributor names, agreements, invoices, incident records and security findings are confidential even when they contain no customer data.
- Start read-only. Do not merge a “test” change, rotate credentials, run migrations, restore over an existing environment, probe another tenant or execute an exploit scan against production.
- Keep production credentials out of the review environment. Builds and package installation can execute project or dependency code. Use an isolated clone or container without production secrets when the seller authorizes execution.
- Do not upload the target to an external AI or scanner by default. Source code, prompts, datasets and logs may be confidential or regulated. Confirm the tool, retention, training, subprocessors and contract before any upload.
- Separate engineering evidence from professional conclusions. Technical reviewers can identify contributors, components and discrepancies. Qualified counsel decides ownership, license obligations, privacy duties and contract treatment; the deal team decides price and whether to proceed.
This guide is a technical evidence model, not legal, tax, accounting, valuation or transaction advice. It is also not a penetration test or a certification.
Start with the deal thesis, not the folder tree
Write the three to six operating promises that must remain true for the acquisition to make sense. Examples:
- existing customers can authenticate, pay and complete the revenue-critical workflow;
- the buyer can control source, cloud, domain, data and releases without the seller's personal accounts;
- the service can support the forecast load and margin within known provider constraints;
- customer data can continue to be used as promised in contracts and privacy notices;
- the product can be restored and operated during a provider, key-person or deployment failure;
- planned integration or modernization does not require an unpriced data migration or platform replacement.
Every diligence finding should point back to one of those promises. A dated library in an isolated admin screen may be ordinary backlog. An unknown payment reconciliation job or a deployment that only the departing founder can perform may affect the transaction's operating premise even if the code is tidy.
1. Establish the complete system boundary
Request: all repositories and organizations, infrastructure-as-code, deployment workflows, cloud projects, databases, object storage, queues, domains, email, payments, monitoring, analytics, model providers, app stores, scheduled jobs and critical manual processes.
Verify: for each item, record legal/account owner, billing owner, named administrators, recovery identity, environment, business purpose, data class, dependent workflow and exit/transfer path. Compare the inventory with DNS, cloud billing, production network calls and recent invoices. A vendor credential in source does not prove the integration is still used; a missing repository entry does not prove the runtime does not depend on it.
Finding: any production dependency that remains outside the inventory is NOT VERIFIED. A supplier-owned account with no transfer path is not “technical debt”; it is an ownership and continuity dependency.
2. Verify source history and change control
Ask for complete repository history rather than a ZIP export. In an authorized local clone, these read-only commands help establish the starting point:
git remote -v
git rev-parse HEAD
git status --short
git branch --all
git tag --sort=-creatordate
git log --format='%aN' --since='24 months ago' | sort | uniq -c | sort -nr
Contributor output is personal and commercially sensitive; keep it in the controlled review record. Counts can be distorted by squash merges, rebases, bots, renamed authors, generated files and work done outside Git. Do not convert one person's commit share into a universal 60% or 70% risk threshold.
Instead, use history to select capability tests. Who can explain the billing workflow? Who can diagnose a failed job, release a change and restore data? Are those people staying, available for transition or represented by an independently usable runbook?
Review branch/ruleset protection, required checks, bypass rights and a sample of critical-path pull requests. GitHub documents how protected branches can require reviews and status checks, but an approval record alone does not prove that the latest change received meaningful review. Read the review discussion and the changed code for a small, risk-based sample.
3. Map source to the production system customers use
The central provenance chain is:
authoritative source revision → reviewed build definition → immutable artifact → deployment record → running workload → configuration schema → database migration state → observed business behavior
Request the current production revision or artifact digest, relevant CI run, deployment record, runtime version marker, environment-variable names, migration ledger and schema comparison. Do not request secret values in a handover document.
If the project can be built, the seller should provide the documented runtime and package-manager versions plus the authoritative lockfile. Execute only in a disposable environment after the build and lifecycle scripts have been reviewed. A successful build proves one reproducibility claim; it does not prove that the resulting artifact matches production or that the application is safe.
A clean repository and a healthy production screen can both be real while still belonging to different revisions.
If the exact source or migration state cannot be reconciled, label the production baseline NOT VERIFIED. The transaction team can then decide whether additional seller evidence, a controlled pre-close exercise or a post-close containment plan is required.
4. Test key-person risk as an operating capability
Do not ask only who wrote the most code. Ask who can perform the actions the buyer will need when something breaks:
- identify the current production version and stop an unintended release;
- find a failed payment, email, webhook, queue or scheduled job;
- rotate a privileged credential without losing the system;
- restore the critical data in isolation;
- explain the top manual workarounds and business exceptions;
- approve and roll back a small change.
Request named primary and backup owners, on-call/support boundaries, transition availability and the runbooks for those actions. Then observe a seller-led demonstration or an authorized independent rehearsal in a safe environment. Documentation is RECEIVED; successful execution by someone other than the sole expert is stronger evidence.
High contributor concentration may be manageable when a second operator can perform the critical tasks and the relevant person is retained for transition. A distributed commit graph can still hide a single founder-owned cloud account or undocumented monthly job. Capability evidence is more useful than a percentage.
5. Reconcile the data model with the business and customer promises
Request a seller-produced schema dump or an authorized read-only schema view, migration history, data dictionary, backup inventory, retention rules, export/deletion process and a restored non-production copy with sanitized or controlled data.
Verify the invariants behind the deal thesis: tenant ownership, subscription state, order/payment reconciliation, entitlements, unique identifiers, orphan handling and the relationship between database rows and object storage. Compare representative counts and definitions with the metrics used in the deal materials, without turning technical diligence into a shadow financial audit.
Backups are an input. NIST contingency guidance treats recovery strategy, testing, training and maintenance as coordinated work. Request the last isolated restore record, what was restored, observed recovery time, integrity/tenant checks and any manual steps. A green backup job remains NOT VERIFIED as recovery evidence until a usable restore has been demonstrated.
Privacy notices, customer contracts and product behavior also need reconciliation. In U.S. acquisition guidance, the FTC has emphasized that customer privacy promises do not disappear in an acquisition. Qualified counsel should assess the target's exact promises, sector, transaction structure and intended post-close use.
6. Sample security and privileged access without creating a new incident
Request the security and incident register, privileged-account inventory, machine identities, security-test history, vulnerability-response process, customer security commitments and open remediation items.
For a bounded technical review, verify that production administration is client/company-controlled, MFA and recovery ownership are known, privileged secrets are not shipped to the browser, and critical object authorization has negative tests. Run secret scanning only with an approved, pinned tool in a controlled clone and redacted output. Do not replace it with a broad search that prints possible secrets into terminal or CI history.
The 12-gate AI-built app production audit contains the deeper evidence sequence for authorization, secrets, data, dependencies, recovery and release. Diligence should record whether that deeper work was performed and what remains unknown; a two-day review cannot become a penetration test by adding more scanners.
If the product is already moving through a customer's vendor review, continue with the enterprise security questionnaire guide for inherited software. It turns the technical evidence into scoped, approved answers without treating acquisition diligence or an old questionnaire as current production truth.
7. Build the dependency and open-source evidence set
Request manifest and lockfiles, supported runtime versions, the dependency graph, vulnerability findings, update ownership, software bill of materials, license notices and the target's open-source review process.
GitHub can export an SPDX SBOM from its dependency graph. It can include versions, package identifiers, declared licenses and transitive paths for supported ecosystems. Treat that as an inventory starting point: unsupported manifests, vendored code, copied snippets, build images and runtime-installed components may require additional discovery.
The Linux Foundation/OpenChain M&A assessment material covers more than license names: discovery, approval, fulfillment of obligations, contribution practices, policy, training, verification and inventory maintenance all matter.
Do not label every GPL or AGPL item an automatic deal blocker. The exact component, license version, modification, integration, distribution and network use matter. The FSF's GNU license FAQ explains the source-offer requirement for users interacting remotely with a modified AGPL program; that is not the same as saying every SaaS dependency creates the same obligation. Inventory the facts and let qualified open-source counsel decide compatibility and required treatment.
8. Give counsel a traceable rights and authorship map
Engineering can make the legal review faster without pretending to complete it.
Create a contributor-to-document matrix: contributor identity, employment/contractor/agency relationship, contribution period, repositories or assets touched, governing documents produced and any unresolved identity. Include infrastructure code, mobile signing material, designs, datasets, prompts, model artifacts, documentation and supplier-created components—not only application source.
The U.S. Copyright Office's Circular 30 explains that work made for hire arises in two defined situations and depends on the facts at creation. Separately, 17 U.S.C. §204 generally requires a signed writing for a copyright transfer. Employee status, scope of duties, commissioned-work categories, contract language, foreign contributors and pre-existing components require project-specific legal analysis.
A name in Git with no matching document is a question for counsel, not proof that the company lacks ownership. A paid invoice or repository admin role is likewise not a legal conclusion.
9. Reconcile infrastructure and provider economics
Request recent cloud, database, observability, email, storage, payment, search, model and other material vendor invoices over a period that shows current usage and meaningful seasonality. Map each line item to the product flow, account owner, contract/plan, renewal, quota, rate limit, support route, exit/export path and forecast driver.
Then separate:
- fixed operating cost that transfers with the asset;
- usage-sensitive cost tied to customers, transactions, storage, messages or model calls;
- transition cost to move accounts, ownership, regions or architecture;
- unverified cost where invoices, metering definitions or shared accounts cannot be reconciled.
Do not infer unit economics from one month's invoice or estimate future margin from current model pricing alone. Use the buyer's forecast, provider terms and measured workload. Finance and the deal team own the economic conclusion.
10. Add three AI-specific evidence lanes
“Uses AI” is not one risk category.
AI-assisted development
Visible Git attribution can help route review, but it cannot measure the percentage of AI-written code. The 2026 preprint Debt Behind the AI Boom analyzed 302,579 explicitly AI-attributed commits in 6,299 popular public repositories and found that 22.7% of tracked static-analysis findings remained at the latest revision.
The limitations matter more in diligence: the study covers Python, JavaScript and TypeScript, sees only explicit attribution, has no reliable human-only baseline and includes static patterns that are not automatically exploitable. Use AI provenance to select high-change, low-review areas—not to calculate an acquisition discount.
Third-party model or API dependency
Request the exact provider, account owner, model/version policy, terms, data retention/training settings, subprocessors, regions, quotas, rate limits, cost alerts, fallback, kill switch and provider-exit path. The FTC has specifically warned AI providers and users about privacy and confidentiality commitments around customer data.
Proprietary model, retrieval layer or dataset
Request dataset and model lineage, collection/licensing/consent records, filtering and deletion processes, model and prompt versions, evaluation sets, known failure modes, human oversight, production monitoring and rollback. NIST's Generative AI Profile highlights third-party component/data risks, intellectual property, privacy, documented evaluation and production monitoring.
Ask for task-specific evaluations that match real deployment conditions. Precision and recall may fit a classifier; they are not universal measures for a generative assistant or agent. Record what the product promises, which test set measures it, the threshold, last run, production trend and owner.
11. Observe operational proof and transition independence
The strongest evidence is a safe execution that another operator can repeat. Depending on transaction stage and authority, request seller-led or independently authorized evidence for:
- an isolated restore with integrity and critical-flow checks;
- a release and rollback record tied to an exact revision and artifact;
- a test alert reaching a named responder;
- a failed provider event reaching a visible retry/reconciliation path;
- a credential-loss or provider-outage tabletop;
- an export that the buyer can actually use;
- a trigger graph showing what a merge, tag, workflow or console action can change.
Do not make a production “test commit” before the release graph and authority are known. Before close, observation, an isolated environment or a seller-executed rehearsal may be the appropriate boundary. After control transfers, the 30-day software project takeover checklist provides the fuller acceptance sequence and first reversible release.
If the acquisition closes and the remaining question is whether to repair, migrate or replace the inherited system, continue with the rewrite, refactor or replatform decision model. It turns the verified diligence baseline into an evidence profile without using a total score as an automatic rewrite verdict.
Received access is not operational acceptance. The transition is safer when recovery, release and rollback can be repeated without the former supplier's personal control.
If the seller or developer has already disappeared, stop treating the work as ordinary diligence and use the first-72-hours recovery runbook to preserve the live system and pursue authorized recovery.
12. Write a technical evidence memo the deal team can use
Keep the decision layer compact and link it to controlled supporting evidence. For every material finding, record:
| Field | Required content |
|---|---|
| Deal-thesis promise | Which operating assumption the finding tests |
| State | VERIFIED, NOT VERIFIED or UNAVAILABLE |
| Severity | P0 deal-thesis blocker, P1 material risk/condition, P2 bounded post-close item |
| Evidence | Exact repository, provider, document, test or observed state |
| Business impact | Customer, revenue, data, margin, transition or roadmap consequence |
| One-time vs recurring | Remediation/transition work versus continuing run cost |
| Resolution path | Seller evidence, containment, repair, transition action or accepted unknown |
| Decision owner | Engineering, security, privacy, counsel, finance or deal lead |
P0 does not automatically mean “walk away,” and P1 does not automatically mean “reduce the price.” It means the evidence contradicts or leaves unbounded a material transaction assumption. Counsel and the deal team choose whether the response belongs before close, at closing, after close or outside the transaction.
Do not hide unknowns inside an average score. A target can have excellent code style and an unavailable production baseline. It can have ordinary technical debt and a well-rehearsed transition. Those are different risk postures even if a numerical grade makes them look similar.
What the technical reviewer cannot conclude alone
A technical report can establish that a component exists, a contributor changed files, a privacy notice says something, a model provider receives data or a restore failed. It cannot alone decide:
- whether the target owns or may transfer every right;
- whether a license is compatible with the proposed use;
- whether past or future data use is lawful;
- whether a security fact triggers notice or contractual remedies;
- what the target is worth or how a finding changes price, escrow or indemnity;
- whether the buyer should complete the transaction.
Those are not disclaimers added after the analysis. They are named decision handoffs with the technical evidence attached.
Frequently asked questions
How long does technical due diligence take for a small SaaS?
There is no defensible universal duration. A focused first pass can triage a bounded product quickly when history, provider access, contracts and restore evidence are ready. Several repositories, regulated data, incomplete history, a custom AI system or failed recovery can require a deeper review. State what was verified within the window and what remains unavailable; do not turn a deadline into false confidence.
Do we need full source access before signing?
The access sequence depends on confidentiality, transaction stage and the parties' agreements. Some evidence can be reviewed through inventories, screen shares, seller-run checks or a controlled clean room before broader access. A ZIP without history is weaker than a full repository, and a repository without production/provider evidence is still incomplete. Counsel and the deal team should set the access protocol.
Should AI-generated code reduce the price?
Not by authorship alone. Visible attribution is incomplete, and current evidence does not produce a target-specific quality or valuation percentage. Review coverage, correctness, authorization, maintainability, production provenance, operating cost and transition evidence are more actionable.
Is a clean dependency or vulnerability scan enough?
No. It covers the tool's supported inputs at one point in time. It does not prove source-to-production parity, authorization, data integrity, restore capability, license compatibility, provider ownership or the absence of copied/vendored code.
What should a seller prepare?
Prepare the system inventory, authoritative repositories/history, source-to-production map, account and vendor register, migration state, SBOM and license process, rights documents for counsel, incident/security register, recent invoices, restore/release evidence, AI inventory and named transition owners. Evidence readiness reduces ambiguity without pretending the system has no debt.
What happens after the technical memo?
The deal team assigns each material item to the correct owner and transaction stage. If the acquisition proceeds, convert the memo into a transition charter, account transfer plan, recovery rehearsal and first safe release. H Product Studio's software project takeover service covers that controlled transition. A stable product may move into application maintenance; verified architectural constraints can inform application modernization.
If you need a scoped technical assessment, describe the target, transaction stage and evidence currently available. Do not send source archives, contracts, credentials, customer exports or other confidential diligence material through the contact form.
Research reviewed on 25 August 2026 against NIST SSDF and recovery guidance, CISA Secure by Demand, current GitHub dependency/SBOM/review documentation, OpenChain M&A material, U.S. Copyright Office and Title 17 sources, FTC acquisition and AI-data guidance, NIST AI RMF and the scoped 2026 AI-code preprint. Recheck official sources and the exact transaction facts before relying on the article.
