Multi-tenant SaaS Product Shell
Next.js product shell with auth callback, org-ready routing, CSP, Notion content, and Docker standalone deploy.
Problem
AI and B2B products need a hardened web shell — identity, tenancy boundaries, security headers, and a deployable server — before features matter.
Overview
This repository is a production-oriented Next.js frontend: marketing + product routes, Google auth callback UI, company-scoped paths, security middleware, and a standalone Docker build.
Solution
Use App Router for pages, middleware for CSP/rate limits, and standalone output for container deploys. Keep tenant paths explicit (`/c/[company]`).
Architecture
Browser → Next middleware (CSP nonce, rate limit) → RSC/client pages → auth callback → tenant routes → Notion/data layer → CDN assets.
- Browser
- Middleware
- App Router
- Auth
- /c/[company]
- APIs / Notion
Implementation
- TypeScript throughout.
- Radix/shadcn UI primitives.
- React Query + Redux where product state needs it.
- PostHog analytics wiring.
- Multi-stage Docker image for `server.js`.
Data model
Tenant/user data lives behind APIs; frontend assumes org-scoped resources via route params.
API design
REST-style data-fetching modules; auth callback route for OAuth return.
Tradeoffs
- Shared marketing + app repo for speed vs split deploys.
- Notion CMS convenience vs custom content service.
Challenges
- CSP without breaking third-party scripts.
- Reproducible standalone Docker builds.
Reliability
- Middleware rate limiting.
- Typed boundaries reduce whole classes of UI bugs.
Security
- CSP nonces.
- Auth callback isolation.
- Security headers in Next config.
Performance
No invented Lighthouse scores. Bundle and route performance are improved by avoiding unused marketing weight on primary pages.
What I learned
- A good product shell is infrastructure for every later feature.
- Security headers are easier early than bolted on later.
Highlights
- App Router + auth callback
- CSP nonce + rate limiting
- Standalone Docker output
- Company-scoped routes