A multi-tenant SaaS built in a 92-hour AI-augmented engineering sprint

01 Measured checkpoints 92hreported compressed engineering sprint 91,344tracked repository text lines — not pure production LOC 50canonical forward-only PostgreSQL migrations at Release 1.5 527 / 527automated tests passing at the sealed Production Readiness checkpoint 244.5 msp95 in the controlled pilot capacity baseline 100 / 100requests passed at concurrency 10, with 0 failures These figures belong to independently verifiable engineering checkpoints and are not presented as if every number originated from the exact same Git SHA. 02 Stack and architectural choices Principal stack TypeScript Node.js 24 React 19 TanStack React Start + Router Vite Supabase PostgreSQL 17 Native CSS GitHub Actions Deliberate constraints No application ORM. Persistence uses Supabase clients, explicit SQL migrations, and narrow PostgreSQL RPCs. No Tailwind as the canonical styling layer. The product design system uses native CSS custom properties and semantic React primitives. These are project-specific architectural choices, not universal recommendations. 03 Multi-tenant trust chain Platform → Organization → Location → Project → Product / Module Data Organization is the primary tenant and security boundary. Location and Project are subordinate scopes. Supabase Auth → Application User → Membership → Organization → Trusted Tenant Context → Permission Engine → Server Operation → PostgreSQL / RPC → Row Level Security Authentication ≠ authorizationMembership ≠ permissionServer authorization ≠ RLSRLS ≠ server authorization Browser-supplied tenant identifiers express intent, not authority. The server independently resolves current identity, membership, tenant context, and permissions before consequential operations. 04 How the AI context limit was handled AI context = disposable working memory. Git + immutable SQL migrations + tests + contracts + hosted database state = durable engineering memory. The process did not depend on a model remembering migration 1 while implementing migration 40. Earlier engineering decisions were externalized into canonical repository artifacts: immutable migration history, architecture contracts, exact SHAs, CI gates, tests, role and permission registries, schema fingerprints, and hosted verification evidence. Before extending a domain, the relevant state was reconstructed from those artifacts. The model was not the system of record; the engineering system was. 05 RLS and cross-tenant isolation RLS validation went beyond checking that policies existed in SQL files. Hosted Supabase environments were exercised with independent tenant fixtures. User A → Organization A → ALLOW User A → Organization B → DENY / no unauthorized rows User B → Organization B → ALLOW User B → Organization A → DENY / no unauthorized rows Additional adversarial controls included: anonymous denial forged Organization IDs forged Membership IDs forged Auth metadata inactive Memberships inactive Organizations revoked authority direct Product-table writes cross-environment JWT rejection logout invalidation A global Super Admin fixture can legitimately see across tenants and therefore mask isolation failures. Synthetic platform authority was prevented from contaminating tenant-local negative controls. 06 Atomic security mutations + audit validate current actor → validate tenant → validate role-assignment authority → INSERT role assignment → append RoleAssigned audit event → COMMIT Privileged mutation and required audit append execute in the same PostgreSQL transaction. If the audit append fails, PostgreSQL rolls back the mutation. Audit history is append-oriented; direct historical UPDATE and DELETE are rejected. 07 What 91,344 tracked lines actually means 91,344 tracked lines does not mean 91,344 lines of hand-written production application code. Repository surfaceApprox. linesApprox. share PostgreSQL migrations + SQL verification~30,00032.8% Server/backend TypeScript~12,50013.7% React/TSX/CSS/i18n frontend~10,50011.5% Automated tests + hosted verification scripts~16,50018.1% CI/tooling/configuration~5,5006.0% Engineering docs/metadata/lockfiles~16,34417.9% Total tracked text91,344100% The category breakdown is an analytical estimate, not a cloc-certified set of subcounts. 08 50 forward-only PostgreSQL migrations At the Release 1.5 checkpoint, the canonical repository-controlled chain contained exactly 50 migrations. Historical migrations are immutable; corrections are forward-only. Migration governance checks deterministic filenames, UTC timestamps, strict chronological ordering, expected authorization of the migration set, and historical immutability. Existing migrations cannot be modified, deleted, or renamed as a shortcut for rollback. 09 527 / 527 automated tests The main repository suite uses the native Node.js test runner: node --test At the sealed Production Readiness checkpoint: 527 tests, 527 passed, 0 failed. Coverage included domain contracts, lifecycle transitions, authorization boundaries, migration governance, adversarial security regressions, tenant isolation, hosted verification, and operational behavior. 10 Controlled capacity baseline Requests: 100 Passed: 100 Failed: 0 Concurrency: 10 p50: 89.1 ms p95: 244.5 ms max: 289.0 ms p95 threshold: 1,500 ms This is a controlled pilot baseline, not a maximum-scale or hyperscale benchmark. No claim is made about thousands of concurrent tenants. 11 Reference productivity scenario Not an industry benchmark. 2 engineers × 8 months × 180 engineering hours/month = 2,880 reference human-engineering hours 2,880 / 92 = 31.3× The assumptions are shown explicitly so a reader can accept, reject, or substitute a different baseline. The measured 92-hour project cycle and the hypothetical 2,880-hour comparison scenario should not be confused. 12 What this case study does not claim It does not claim 91,344 lines of hand-written production code. It does not claim that LOC proves software quality. It does not claim that 92 hours is a verified world record. It does not claim that 100 requests is a hyperscale benchmark. It does not claim that AI eliminated engineering judgment. It does not claim that context-window limits disappeared. It does not claim that every engineering organization would reproduce the same speed. Bottom line The interesting claim is not that AI writes code fast. The engineering experiment is whether development time can be compressed while preserving multi-tenancy, authentication, RBAC, RLS, auditability, forward-only database evolution, operational workflows, CI gates, hosted adversarial verification, and measurable performance evidence. FAST & FLOW suggests that substantial engineering compression may be possible when AI operates inside a system governed by Git, tests, migrations, security boundaries, CI, and reproducible evidence. Explore FAST & FLOW