{"slug": "a-multi-tenant-saas-built-in-a-92-hour-ai-augmented-engineering-sprint", "title": "A multi-tenant SaaS built in a 92-hour AI-augmented engineering sprint", "summary": "A multi-tenant B2B SaaS was built in a 92-hour AI-augmented engineering sprint, with 91,344 tracked repository text lines, 50 canonical forward-only PostgreSQL migrations at Release 1.5, 527/527 automated tests passing at the Production Readiness checkpoint, and a 244.5 ms p95 in the controlled pilot capacity baseline. The case study details the architecture, including a trust chain from Platform to Organization to Location to Project, and emphasizes that AI context is disposable working memory while Git, migrations, tests, and hosted database state form durable engineering memory.", "body_md": "**92h** reported compressed engineering sprint\n\nFAST & FLOW · TECHNICAL ENGINEERING CASE STUDY\n\n# Engineering compression with preserved structure.\n\nAn AI-augmented, multi-tenant B2B SaaS built under an unusually compressed engineering cycle.\n\nThe production source repository remains private. This public case study exposes architecture, methodology, measured engineering checkpoints, limitations, and testing strategy without exposing credentials, proprietary source code, or client data.\n\n01\n\n## Measured checkpoints\n\n**91,344** tracked repository text lines — not pure production LOC\n\n**50** canonical forward-only PostgreSQL migrations at Release 1.5\n\n**527 / 527** automated tests passing at the sealed Production Readiness checkpoint\n\n**244.5 ms** p95 in the controlled pilot capacity baseline\n\n**100 / 100** requests passed at concurrency 10, with 0 failures\n\nThese figures belong to independently verifiable engineering checkpoints and are not presented as if every number originated from the exact same Git SHA.\n\n02\n\n## Stack and architectural choices\n\n### Principal stack\n\n- TypeScript\n- Node.js 24\n- React 19\n- TanStack React Start + Router\n- Vite\n- Supabase\n- PostgreSQL 17\n- Native CSS\n- GitHub Actions\n\n### Deliberate constraints\n\n**No application ORM.** Persistence uses Supabase clients, explicit SQL migrations, and narrow PostgreSQL RPCs.\n\n**No Tailwind as the canonical styling layer.** The product design system uses native CSS custom properties and semantic React primitives.\n\nThese are project-specific architectural choices, not universal recommendations.\n\n03\n\n## Multi-tenant trust chain\n\n```\nPlatform\n  → Organization\n      → Location\n          → Project\n              → Product / Module Data\n```\n\n**Organization** is the primary tenant and security boundary. Location and Project are subordinate scopes.\n\n```\nSupabase Auth\n  → Application User\n  → Membership\n  → Organization\n  → Trusted Tenant Context\n  → Permission Engine\n  → Server Operation\n  → PostgreSQL / RPC\n  → Row Level Security\n```\n\nBrowser-supplied tenant identifiers express intent, not authority. The server independently resolves current identity, membership, tenant context, and permissions before consequential operations.\n\n04\n\n## How the AI context limit was handled\n\nAI context = disposable working memory. Git + immutable SQL migrations + tests + contracts + hosted database state = durable engineering memory.\n\nThe 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.\n\nBefore extending a domain, the relevant state was reconstructed from those artifacts. The model was not the system of record; the engineering system was.\n\n05\n\n## RLS and cross-tenant isolation\n\nRLS validation went beyond checking that policies existed in SQL files. Hosted Supabase environments were exercised with independent tenant fixtures.\n\n```\nUser A → Organization A → ALLOW\nUser A → Organization B → DENY / no unauthorized rows\n\nUser B → Organization B → ALLOW\nUser B → Organization A → DENY / no unauthorized rows\n```\n\nAdditional adversarial controls included:\n\n- anonymous denial\n- forged Organization IDs\n- forged Membership IDs\n- forged Auth metadata\n- inactive Memberships\n- inactive Organizations\n- revoked authority\n- direct Product-table writes\n- cross-environment JWT rejection\n- logout invalidation\n\nA 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.\n\n06\n\n## Atomic security mutations + audit\n\n```\nvalidate current actor\n→ validate tenant\n→ validate role-assignment authority\n→ INSERT role assignment\n→ append RoleAssigned audit event\n→ COMMIT\n```\n\nPrivileged 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.\n\n07\n\n## What 91,344 tracked lines actually means\n\n91,344 tracked lines does not mean 91,344 lines of hand-written production application code.\n\n| Repository surface | Approx. lines | Approx. share |\n|---|---|---|\n| PostgreSQL migrations + SQL verification | ~30,000 | 32.8% |\n| Server/backend TypeScript | ~12,500 | 13.7% |\n| React/TSX/CSS/i18n frontend | ~10,500 | 11.5% |\n| Automated tests + hosted verification scripts | ~16,500 | 18.1% |\n| CI/tooling/configuration | ~5,500 | 6.0% |\n| Engineering docs/metadata/lockfiles | ~16,344 | 17.9% |\nTotal tracked text | 91,344 | 100% |\n\nThe category breakdown is an analytical estimate, not a cloc-certified set of subcounts.\n\n08\n\n## 50 forward-only PostgreSQL migrations\n\nAt the Release 1.5 checkpoint, the canonical repository-controlled chain contained exactly 50 migrations. Historical migrations are immutable; corrections are forward-only.\n\nMigration 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.\n\n09\n\n## 527 / 527 automated tests\n\nThe main repository suite uses the native Node.js test runner:\n\n```\nnode --test\n```\n\nAt 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.\n\n10\n\n## Controlled capacity baseline\n\n```\nRequests:       100\nPassed:         100\nFailed:         0\nConcurrency:    10\np50:            89.1 ms\np95:            244.5 ms\nmax:            289.0 ms\np95 threshold:  1,500 ms\n```\n\nThis is a controlled pilot baseline, not a maximum-scale or hyperscale benchmark. No claim is made about thousands of concurrent tenants.\n\n11\n\n## Reference productivity scenario\n\n**Not an industry benchmark.**\n\n2 engineers × 8 months × 180 engineering hours/month = 2,880 reference human-engineering hours\n\n2,880 / 92 = **31.3×**\n\nThe 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.\n\n12\n\n## What this case study does not claim\n\n- It does not claim 91,344 lines of hand-written production code.\n- It does not claim that LOC proves software quality.\n- It does not claim that 92 hours is a verified world record.\n- It does not claim that 100 requests is a hyperscale benchmark.\n- It does not claim that AI eliminated engineering judgment.\n- It does not claim that context-window limits disappeared.\n- It does not claim that every engineering organization would reproduce the same speed.\n\nBottom line\n\n## The interesting claim is not that AI writes code fast.\n\nThe 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.\n\nFAST & 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.\n\n[Explore FAST & FLOW](/explore)", "url": "https://wpnews.pro/news/a-multi-tenant-saas-built-in-a-92-hour-ai-augmented-engineering-sprint", "canonical_source": "https://fast-and-flow-production.onrender.com/case-study", "published_at": "2026-08-19 09:22:25+00:00", "updated_at": "2026-08-19 09:42:36.829239+00:00", "lang": "en", "topics": ["ai-tools", "ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["TypeScript", "Node.js 24", "React 19", "TanStack React Start", "Vite", "Supabase", "PostgreSQL 17", "GitHub Actions"], "alternates": {"html": "https://wpnews.pro/news/a-multi-tenant-saas-built-in-a-92-hour-ai-augmented-engineering-sprint", "markdown": "https://wpnews.pro/news/a-multi-tenant-saas-built-in-a-92-hour-ai-augmented-engineering-sprint.md", "text": "https://wpnews.pro/news/a-multi-tenant-saas-built-in-a-92-hour-ai-augmented-engineering-sprint.txt", "jsonld": "https://wpnews.pro/news/a-multi-tenant-saas-built-in-a-92-hour-ai-augmented-engineering-sprint.jsonld"}}