This is a code-only SaaS due diligence checklist for buyers who cannot read a repository. It does not cover revenue, churn, contracts, tax, or valuation.
Each check tells you what can go wrong, what to look for, how to check it yourself where possible, and whether Ascertify verifies it from the repository. Fifteen of the 25 are fully automated. Nine need something only the seller can give you. One is on the roadmap and marked as such.
If you are buying through Flippa or Acquire.com, use their broader acquisition guidance for the rest of the deal. This page deliberately goes narrower: these are the checks for the code you are about to inherit.
Financial diligence can tell you whether customers pay. It cannot tell you whether the product depends on a leaked API key, whether users can access each other's data, whether somebody else can rebuild and deploy the code, or whether the seller is the only person who knows how the product stays alive.
That matters because the repository is part of what you are buying. Healthy MRR does not make unsafe database rules, abandoned dependencies, disputed code ownership, or undocumented deployment steps disappear.
Use this checklist after you receive repository access and before the inspection period closes. For the wider process, see micro-SaaS due diligence, technical due diligence for non-technical buyers, and what technical due diligence costs.
Removing a secret from the current file does not make an exposed credential safe. It is still in the history, and anyone with the repository can read it. GitHub's own guidance is to rotate a leaked credential rather than treat deletion as remediation.
Stripe keys, AI provider keys, database passwords, tokens, private keys, or signing secrets committed directly in source files.
API_KEY, SECRET, TOKEN, PASSWORD, PRIVATE_KEY, .env, and provider names. A match is not automatically a leak. An actual credential value is.Credentials removed from today's code but still present in an earlier commit.
gitleaks or trufflehogagainst the full history and share the output. Both are free. Do not ask for GitHub secret-scanning results; on private repositories that is a paid feature most solo founders do not have. “We deleted it” is not sufficient. Exposed production credentials should have been rotated.The same credentials being used across local development, staging, testing, and production.
Service-role keys, admin SDK credentials, private signing keys, database connection strings, or unrestricted provider keys inside frontend code, or any variable prefixed for the browser (NEXT_PUBLIC_, VITE_) whose name contains “secret” or “private”.
Keys tied to the seller's personal account, an agency account, or a developer who is leaving after the sale.
Authentication answers “who are you?” Authorization answers “what are you allowed to access?” The second one is where ugly acquisition surprises hide.
OWASP recommends denying access by default and validating permissions on every request. Supabase similarly requires appropriate grants and row-level security for exposed database tables.
This is not theoretical. In the research behind CVE-2025-48757, 170 of 1,645 analyzed Lovable projects, about 10.3%, exposed affected database endpoints. Researchers reported 303 vulnerable endpoints. The CVE describes insufficient row-level security allowing unauthenticated access to generated sites' database tables.
Authentication that works, but authorization that fails between users, accounts, or workspaces.
Missing or overly permissive Firebase rules, Supabase RLS policies, database grants, or backend authorization middleware. Note that RLS enabled with no policies on a table behaves the same as RLS disabled.
Private invoices, exports, identity documents, attachments, or customer uploads stored in publicly readable buckets.
A repository is not transferable just because it worked on the seller's laptop. You want evidence that another person can install, build, test, deploy, and change it predictably.
Test folders, test scripts, CI test steps, and unit, integration, or end-to-end tests.
tests, __tests__, spec, e2e, and scripts named test, test:unit, or similar.Tests around signup, billing, permissions, and the core paid workflow, not fifty tests for formatting helpers.
A committed lockfile that has been maintained alongside the manifests, plus clear install and build scripts. A lockfile that stopped changing while package.json kept changing is a warning sign.
npm documents that package-lock.json records the exact dependency tree so later installs reproduce it rather than silently pulling different versions.
package-lock.json, pnpm-lock.yaml, yarn.lock, poetry.lock, or the equivalent for the stack, and compare its last change date with the manifest's.README instructions, environment-variable examples, migrations, infrastructure configuration, CI workflows, deployment steps, and rollback guidance.
Six signals, none of which need a score. No tests (already covered above). Files over a few hundred lines. The same logic duplicated in several places. TypeScript with any everywhere. Dependencies with no release in two or more years. A git history that shows a dump rather than development.
Most SaaS products contain far more third-party code than code written by the seller. GitHub builds its dependency graph from manifests and lockfiles, while SPDX exists specifically to represent software components, provenance, licensing, and security information.
Packages in the manifest that are not on the registry, or that exist but were published after the code that imports them. AI coding tools invent plausible package names, and squatters register those names with malicious code. Also look for imports in the source that no declared package provides.
Security advisories affecting packages that actually ship in production.
npm audit, Snyk, or equivalent results. Prioritize exploitable production dependencies over the raw number of alerts.Deprecated runtimes, abandoned frameworks, unsupported major versions, or SDKs that no longer receive fixes.
Copyleft, source-available, custom, unknown, or commercial licenses with obligations the seller may have ignored.
Open-source software can carry conditions even when it is free to use, so “it's open source” is not the end of the licensing check.
Git URLs, local paths, personal forks, private registries, and packages with no credible maintenance path.
Git history is not decoration. It shows how the product evolved, who worked on it, and whether you received a maintained repository or a ZIP file wearing a GitHub costume.
Incremental feature work, fixes, releases, refactors, and normal changes over time.
Heavy concentration of commits or code contribution in one person.
GitHub's contributor graph exposes the repository's top contributors, which gives a buyer a straightforward first view of authorship concentration.
Major Git contributors who are not explained by employee, contractor, or cofounder records.
A recently created repository containing old code, missing history, or dates that do not match the seller's story.
A technically decent product can still be a terrible acquisition if one person is required to keep it alive.
Current Flippa SaaS buying guidance explicitly tells buyers to focus on transferability and founder dependency. Acquire.com's technical diligence guidance similarly examines who is behind the software and who owns the code.
Hidden prerequisites, undocumented migrations, missing environment details, or setup steps known only to the seller.
Manual imports, cron jobs, backup routines, certificate renewal, queue restarts, billing tasks, or cleanup that lives in the founder's head.
Personal GitHub apps, cloud projects, OAuth clients, domains, Stripe webhooks, email services, analytics accounts, or AI services that cannot simply move with the source code.
A non-technical buyer can do a useful first pass without reading application code.
Start with what GitHub makes visible: commit history, contributors, test folders, README files, lockfiles, dependency alerts, configuration files, and the largest source files. Then ask the seller to demonstrate authorization with two accounts and provide an inventory of production services.
The harder questions are the ones where intent or live behavior matters: whether authorization rules are correct, whether tests cover the right business paths, whether a dependency is dangerous in context, and whether operational knowledge exists outside the repository.
That is the difference between a checklist and an audit.
The checklist tells you where to look. Ascertify runs the 15 automated checks against the repository and turns the findings into buyer-facing evidence, every one anchored to a file and a line, for $49. It reads the code and never executes it, and it does not pretend the seller's production environment can be inferred from source.
Check six areas: secrets and credentials, database and authorization rules, tests and maintainability, dependencies and licenses, Git history and authorship, and bus factor and handover.
The 25 checks above cover those areas without requiring you to judge code quality line by line.
Not for every check.
A non-technical buyer can verify repository history, contributor concentration, documentation, tests, lockfiles, dependency alerts, file sizes, and many exposed-secret signals. Bring in a developer or specialist when a finding depends on runtime behavior, architecture, security intent, or remediation cost.
A SaaS due diligence checklist covers the business: revenue, customers, legal, operations, technology, and transfer.
A code due diligence checklist covers the software asset itself: repository history, security configuration, dependencies, tests, licenses, authorship, and handover evidence.
It works for a deal found on either marketplace, but it is not affiliated with Flippa or Acquire.com.
Their guides cover the wider acquisition. This checklist is intentionally code-only so you can use it beside a listing, data room, or repository.
AI can assist, but useful findings should resolve to concrete evidence: a file, dependency, rule, commit, credential pattern, or configuration.
Live authorization, production infrastructure, account ownership, and seller handover claims still need external verification.
For a deal under $50,000 with repository access, one working day is enough for the repository checks on this list, and most of the automated ones take minutes. Budget a second day for the seller conversations in the Partial items. Larger deals, customer data, or heavy founder dependency justify more.
Treat any critical security, code-ownership, or transferability finding as a reason to investigate before the inspection period closes.
Use the one-page version during the repository review, then return here when a failed check needs explanation.
Or skip the manual repository pass:
Independent service. Not affiliated with Acquire.com, Flippa, TrustMRR or any other marketplace.