Auditing an AI-Built SaaS: The LastSaaS Release Checklist Field Note

This is an independent public-source walkthrough of jonradoff/lastsaas at commit c692923e.

LastSaaS describes itself as a complete SaaS foundation built entirely through conversation with Claude Code: multi-tenant accounts, JWT and OAuth authentication, MFA, Stripe billing, API keys, outgoing webhooks, an admin interface, health monitoring, and an MCP server for AI-powered administration. That makes it a genuinely useful subject for this series — not because being AI-built creates risk (nothing in this note treats that as a defect), but because it is exactly the kind of codebase a founder forks, extends agentically, and then has to ship to real customers.

This is not an endorsement, a maintainer-approved review, a penetration test, or a customer case study. It is method proof from public source. A product built on this foundation would have its own code, configuration, secrets, provider accounts, data, and risk boundary.

Source snapshot

What the deterministic passes observed

The structural signals were unusually clean for a codebase of this size. Across 226 modules and 280 internal import edges the graph pass found zero import cycles and zero unused exports. Go and TypeScript test conventions sit beside the code throughout: 33 Go _test.go files and 5 TypeScript suites, with GitHub Actions CI, Vitest, and Playwright signals present.

The passes also surfaced honest concentration risk. Authentication logic sits in one 2,073-line Go file, the admin surface in a 1,739-line file, and billing, docs, and plan management each in files near or above a thousand lines. None of that is a defect claim — it is a maintainability observation that matters when several agents or several people start editing a fork at once.

Four low-severity dependency advisories existed in the frontend toolchain at the reviewed commit. That is routine hygiene, not a headline.

Every code-level security finding was rejected — and that is the story

The first analyzer run reported 21 security-relevant findings against the repository's own code: 16 possible committed secrets and 5 timing-unsafe secret comparisons.

Manual review rejected all 21.

• Every "committed secret" was a fixture inside a Go _test.go file — test passwords, not production credentials.
• Every "timing-unsafe comparison" was either a password-confirmation prompt (comparing two values the same user just typed) or an enum check like an API key's authority level being compared to a role constant. No secret bytes were being compared in any of them.

We did not publish around those findings; we fixed the analyzer. Before this note went out, CodeTruss shipped four precision fixes: test-fixture recognition for Go, Python, and Ruby conventions, leaf-level name resolution so apiKey.Authority is not treated as the key itself, suppression for the password-confirmation idiom, and test-file classification that now counts _test.go toward coverage signals. Re-running the same pinned commit afterward produced zero code-level security findings.

That sequence — analyzer output, human adjudication, engine correction, re-run — is the Release Assurance method working as designed. Automated review narrows attention; it does not get to make claims on its own.

Where the analyzer states its own limits

CodeTruss discloses its own coverage limits for Go rather than letting a quiet green score imply analysis that never ran. When this review was performed, its deep source-to-sink analysis did not reach Go at all. The engine has since gained Go dataflow for SQL injection and OS command injection, and re-running this same pinned commit still produced no code-level security findings — LastSaaS stores data in MongoDB, so there is no string-built SQL for those rules to reach.

Coverage for Go remains partial, and the report says so: the untrusted-input catalog is still tuned for TypeScript, JavaScript and Python. For a Go-majority codebase that disclosure is itself release-relevant, because it tells a team which assurance still has to come from tests, review, and staged verification rather than from this analyzer.

Release checklist produced from source evidence

None of those rows says LastSaaS is broken. They say a team building on this foundation should know which proof is still required for its own release state.

What public source could not prove

Public repository review could not prove browser behavior in a deployed environment, API behavior with live credentials, database state after webhook retries, payment-provider account configuration, email deliverability, background timing behavior, or tenant and role behavior in a buyer-specific fork. Those gaps are why a paid Release Assurance pilot contracts an exact release state and exercises the critical workflows against staging before the release call.

What this walkthrough proves and does not prove

It proves a pinned public repository can become a concrete release checklist without private access, and it proves the adjudication step is real: in this run, human review overturned every automated security finding and the engine was corrected before publication.

It does not prove customer demand, revenue, maintainer approval, production behavior, or any vulnerability in LastSaaS.

If you are preparing an AI-assisted SaaS release, see the fixed-scope CodeTruss Release Assurance pilot. The first risk screen does not require repository access: bring the target release date, stack, current testing state, staging readiness, and three workflows that cannot fail.

Source: jonradoff/lastsaas, provided under the MIT license. CodeTruss is not affiliated with, sponsored by, or endorsed by the LastSaaS project or its author.