Developer audits his own SaaS starter kit like a hostile buyer

The creator of NuxtForge, a Nuxt 4 + NestJS 11 SaaS starter kit, decided to audit his own product like a skeptical buyer before putting a price on it — cloning it fresh, following only the README, with no memory of having built it. The review surfaced four real problems: a test script that pointed at no actual test configuration, a fresh clone that failed to boot due to four compounding bugs (wrong service hostnames, an ignored dev command, env values corrupted by trailing comments, and a memory-exhausting SSR fetch loop), a seed process that created a tenant but no user to log in with, and — once a real end-to-end suite existed — a genuine tenant-context leak where a scoped query resolved after its context had already exited.

That last catch is the core argument of the piece: architectural intent to prevent cross-tenant leaks isn't proof that leaks can't happen — automated tests against real infrastructure are. After the fixes, the kit ships with a working unit test suite and a mock-free e2e suite running against real Postgres and Redis, fail-closed tenant isolation enforced via a Prisma extension, a Stripe webhook hardened with signature verification, Redis-based idempotency, and server-side amount verification, plus boot-time env validation via Joi.

The broader takeaway for engineers is procedural rather than product-specific: audit any starter kit — including your own — as a hostile buyer would, on a clean clone and an unfamiliar machine, forcing its README claims to be proven rather than assumed. A kit that survives that scrutiny is worth building on; one that doesn't will cost more time than it promised to save.