independent & unofficial · sample report Get the review

← Back to the home page

Sample report from a timed dry run on a public open-source SaaS project. Details are anonymized and condensed. The project is not for sale as far as we know, and nobody commissioned this review. Findings are framed as what a buyer would ask about, not as criticism of the project.

Pre-close tech review · sample

An open-source group-scheduling SaaS

About 100k lines of TypeScript in one monorepo, AGPL-licensed, on a current web framework and PostgreSQL. Hosted on a serverless platform, billed through Stripe, and also sold as a self-hosted licence.

Code reviewed
Main branch at the latest commit on the review date, full git history (about 3,900 commits across all branches)
Access
Seller-scan stand-in on a public production branch: findings and provenance from the scan workflow only (no clone of private code). No production credentials, databases or secrets.
Review date
October 2026
Hypothetical buyer's worry
“Can I keep this running without the founder?” and “Any security or licence surprises?”

One-page summary

Verdict

Technically healthy and actively maintained. One red item: almost all of the code was written by one person. Price that in or cover it with a handover agreement.

CI, backups and central auth checks are strong, and we found no live secrets in the code. The deal risks are about people, accounts and paperwork, not code quality.

Top 5 risks

  1. REDKey-person dependency: one author made about 99% of the commits. L
  2. AMBERAbout 15 vendor accounts and 4 OAuth app registrations to transfer. M
  3. AMBERDependency advisories reachable from production, mostly patch-level fixes. S
  4. AMBERBilling code pinned to a 2023 Stripe API version. M
  5. AMBERAGPL licence with a contributor agreement: relicensing needs records. S

Ask the seller first

  1. Who besides you has deployed or handled an incident in the last 12 months, and what handover will you commit to in writing?
  2. Please list every account the app uses, with its monthly cost, owner login, and whether it transfers.
  3. When was a full restore from backup last tested end to end?
  4. Are the OAuth apps verified for the scopes in use, and in whose developer account?

Effort: S = under 2 engineer-days, M = 2–10, L = more than 10 (rough, for budgeting).

Risk scorecard

AreaRatingWhy
Key-person riskREDBus factor 1: one author wrote about 99% of human commits, all time and in the last 12 months
Dependency vulnerabilitiesAMBER67 package versions with public advisories, 45 reachable from production code (many build-time only). Mostly patch or minor upgrades
Accounts and vendors to transferAMBERAbout 15 external services and 4 OAuth app registrations referenced by the code
Licences and IPAMBERThird-party packages fine for SaaS use. The product is AGPL-3.0 with a contributor agreement: needs records, not code changes
Deploy pipelineAMBERA release tag triggers the production deploy through a secret hook. Database migrations run inside the build
Infrastructure and backupsAMBERNo infrastructure-as-code (set up in vendor dashboards). Good nightly backups, but no restore drill evidenced
Docs and onboardingAMBERGood self-hosting docs. The hosted-production configuration is not documented in the repo
Secrets in code and historyGREEN28 of 29 hits are test fixtures or placeholders. One old key on a legacy branch to confirm revoked
Static analysisGREEN43 rule hits, none actionable in application code after triage
Tests and CIGREENUnit tests, a browser integration suite and a container smoke test run on every push. Coverage not measured
Runtime currencyGREENCurrent runtime and framework versions, none end-of-life. The Stripe library is the exception
Auth and multi-tenancyGREENQuick read: central guards, admin role re-checked in the database, parameterised SQL, scheduled-job routes fail closed
  • RED likely to cost money or block handover
  • AMBER real but bounded; plan for it
  • GREEN no material concern in what we could see

Top 5 risks

Lines that start with Reviewer judgment are our opinion or estimate. Everything else is backed by a file, commit or tool result in the full report.

01

Key-person dependency (bus factor 1)

RED
Evidence
Git history, bots excluded: about 99% of human commits all time, and all but 2 in the last 12 months, are by one author. Over half of recent commits carry an AI-assistant co-author trailer.
Business impact
Architecture, deploy and vendor knowledge sits with one person. Reviewer judgment: without a handover, expect slower shipping and riskier incidents for the first months.
Fix effort
LReviewer judgment: a structured handover of about 10–20 founder-days over 60–90 days.
Deal action
Transition-services agreement with named deliverables, backed by a holdback or earn-out.
Ask the seller
“Who besides you has deployed or handled an incident in the last 12 months?”
02

Many vendor accounts and app registrations to transfer

AMBER
Evidence
The environment schema, hosting config and CI workflows reference: hosting (with scheduled jobs, two of them every minute), a PostgreSQL host, cloud email and backup storage, file storage, a key-value store, Stripe, product analytics, error tracking, bot protection, an AI API, a licence server for self-hosted sales, four calendar and video-meeting OAuth apps, a container registry, and translation and docs platforms.
Business impact
Each account must be taken over or re-created. OAuth apps can need platform re-verification when ownership changes. If one lapses, sign-in or calendar sync breaks for customers.
Fix effort
MReviewer judgment: about 3–5 days of coordinated work, plus vendor lead times.
Deal action
Closing deliverable: a signed-off transfer checklist. Make the domain, Stripe account, OAuth apps and licence server a closing condition.
Ask the seller
“List every account with its monthly cost and owner login. Are the OAuth scopes verified?”
03

Dependency advisories in the production tree

AMBER
Evidence
osv-scanner on the lockfile: 67 package versions with advisories. We traced the lockfile graph: 45 are reachable from production code. Runtime examples, all with fixed versions available: an email library, a rich-text editor (paste XSS), a WebSocket library. No version-update automation is configured. The latest commit was a framework security upgrade.
Business impact
No sign of exploitation: this is routine maintenance debt. A business customer's security questionnaire would flag it.
Fix effort
SReviewer judgment: about 1–3 engineer-days with the existing CI suite.
Deal action
Pre-close fix or a 30-day post-close plan. Not a price item.
Ask the seller
“What is your update routine? Any dismissed security alerts?”
04

Billing pinned to a 2023 Stripe API version

AMBER
Evidence
The billing package uses a Stripe library about 10 major versions behind the latest, pinned to a 2023 API version. Webhooks are signature-verified. Billing tests exist.
Business impact
Works today, but billing is the revenue path. Any new Stripe feature needs this upgrade first, with webhook changes to test.
Fix effort
MReviewer judgment: about 2–5 engineer-days including test-mode runs.
Deal action
Post-close plan with budget. Check the account's default API version during diligence.
Ask the seller
“Which webhook events does production rely on?”
05

Product licence and contributor rights (AGPL-3.0)

AMBER
Evidence
The licence file is AGPL-3.0. The contributing guide requires a contributor agreement that grants relicensing rights. About 30 outside authors have commits.
Business impact
Anyone may run a competing hosted copy, so the moat is brand and customers. The paid self-hosted licence depends on holding relicensing rights to every contribution. That is a question for the buyer's lawyer, not a conclusion.
Fix effort
SPaperwork: match agreement records to contributors.
Deal action
IP rep and warranty, plus the agreement records as a closing deliverable.
Ask the seller
“Since when has the agreement been enforced, and does it cover all outside contributors?”

Questions for the seller

  1. Who besides you can deploy, roll back and restore? When was a full restore last tested?
  2. Account list with monthly costs. Which accounts are personal rather than company-owned?
  3. Are the OAuth apps verified, and in whose developer account?
  4. Does the hosting plan depend on every-minute scheduled jobs that a cheaper plan would not allow?
  5. Migrations run during the build. What is the rollback if one fails half-way?
  6. Dependency update routine, and any dismissed security alerts?
  7. Contributor agreement coverage for all outside contributors?
  8. Please confirm the old key on the legacy branch was revoked.

What looks good

  • Serious CI: type checks, linting, unit tests, a browser integration suite and a container smoke test.
  • Nightly encrypted database backup with a minimal access scope and a size check.
  • Central auth guards; the admin role is re-read from the database.
  • Current stack, no end-of-life runtimes.
  • Onboarding material for people and AI agents is in the repo.

Method and limits

Please read

  • Static review of source code and git history only. Not a penetration test or security audit. Nothing was run against the live product. The code was not built or executed and its tests were not run.
  • Not legal, tax, financial or investment advice, and not a valuation. Licence points are questions for a lawyer.
  • Automated tools miss issues and raise false positives. A green rating is not a guarantee.
  • Production configuration, vendor accounts, data, revenue and contracts were not seen.

How it was done: automated and AI-assisted scans, then hand-checked findings and seller questions. Tools (all free and open source): gitleaks (secrets, all branches, redacted), osv-scanner (advisories and licences), semgrep (public rules), checkov (infrastructure and CI config), scc (size), git history analysis, plus a targeted read of the auth, billing, deploy and backup code. The full report adds a per-area appendix with every file path and tool result.

Data handling for paid reviews: Scan outputs, and any code excerpts quoted in findings, are deleted within 7 days of delivery. Form and order details are deleted within 30 days after the order closes, except records that Stripe or tax rules require us to keep.

Back to SaaS Handoff Check