A Next.js app to production

Before any code, decide the two things that shape everything downstream: how tenancy is keyed and how each route renders. Pick subdomain-per-tenant (clean isolation, more DNS/cert work) over path-per-tenant (simpler routing, easier to leak), and write down the keying rule. Then classify every route by render strategy — static (SSG) for marketing, ISR for published tenant content, dynamic SSR for dashboards — because that classification drives your caching, your edge/node split, and your blast radius later. Write 2–3 SLOs (e.g. p75 LCP < 2.5 s on published pages, p99 TTFB < 200 ms for cached routes) and explicit non-goals so you don't gold-plate the editor when the read path is what carries traffic.

Stand up the App Router skeleton with the server/client boundary drawn deliberately. Keep data fetching in Server Components so credentials and queries never reach the client bundle; push interactivity to small client islands at the leaves, not whole-page 'use client'. Wire mutations through Server Actions instead of hand-rolled route handlers for form posts, and reach for the data layer (ORM/SQL in RSC) directly in the component tree. The test of a good skeleton: a published page ships almost no JS, and the hydration boundary is a thin shell around the interactive bits, not the page.

Make multi-tenant auth airtight. Decide session vs JWT for your case (stateful sessions revoke instantly but need a store; JWTs scale statelessly but you own revocation and rotation), then enforce the tenant boundary at the data layer so every query is scoped by tenant id — never trust the subdomain alone. Mark server-only modules so a secret can never be imported into a client component, keep your DB URL and signing keys out of the bundle, and protect Server Actions against CSRF and against acting on another tenant's resources. The boundary you're proving: a logged-in user of tenant A cannot read, mutate, or even probe tenant B, no matter what they put in the request.

Compose three caches without leaking tenant data or serving stale content forever. Use ISR (the Full Route + Data cache) to make published tenant pages static-fast with background revalidation; put a CDN in front so cached HTML is served from the edge; and tag cache entries by domain (e.g. tenant:{id}, post:{id}) so a single edit invalidates exactly the pages it touched via on-demand revalidation — not a global purge, not a stale page. The trap is the shared cache key: if the CDN or the Data cache keys on URL but not tenant, a request can return the wrong tenant's HTML. Make the tenant part of every cache key and prove invalidation is surgical.

Place every piece of work on the right runtime and keep the page light. The edge runtime is fast to start and close to the user but has a constrained API surface and no native Node modules — right for tenant routing, auth-check middleware, and geolocated rewrites; node is right for your ORM, heavy crypto, and anything pulling Node built-ins. Put the tenant resolution and a cheap auth gate in middleware at the edge; keep DB work on node. Then set an asset budget — optimize images through next/image, subset and self-host fonts to kill layout shift, and analyze the bundle so a stray client import doesn't blow your JS budget. Target: a published page under a defined JS budget (e.g. < 100 KB gzipped) with LCP image properly sized.

Make failure contained and the running app legible. Build the error.tsx / not-found.tsx hierarchy so a thrown error in one route segment degrades that subtree, not the whole app — a failing widget in tenant A's dashboard must not blank tenant B's. Then instrument: register OpenTelemetry via instrumentation.ts, emit RED metrics (rate, errors, duration) on the read and action paths, log structured server-side events you can query by tenant, and propagate traces across the RSC → data-layer hops so a slow page points at the slow span. Turn your SLOs into a dashboard with an error budget so you see the incident before the next milestone hands you one.

Ship it the way you'd run it for tenants. Choose self-host vs a managed platform with eyes open — a managed platform gives you ISR/CDN/edge for free but bills per invocation and per GB-served; self-hosting on node gives control but you own the cache store and the CDN wiring. Whichever you pick, fix the serverless database problem: a per-invocation connection storm will exhaust Postgres, so put a pooler (PgBouncer or the platform's data proxy) between the app and the DB. Wire a pipeline that gates on the tenant-isolation test from the auth milestone, keep secrets injected at deploy, and make a bad rollout reversible in seconds.

A request with an unkeyed header (or a tenant-blind cache key) makes Next.js cache the wrong response into the shared ISR/CDN entry; now tenant B is served tenant A's HTML — or an attacker-controlled page — until the entry revalidates, and a parallel cold-start storm during revalidation spikes TTFB. Detect it from your own metrics (a jump in cross-tenant 200s, a TTFB spike on revalidation), mitigate it live (purge the poisoned tag, narrow the cache key, drop the unkeyed input), find the root cause, and write the post-mortem. The fix that holds is keying the cache on everything that varies the response — tenant, auth state, the headers you actually read — plus request coalescing on revalidation so a cold ISR entry doesn't trigger a thundering herd. 'Shorten the TTL' is not a fix; it only narrows the poisoning window.