You lead a Next.js App Router codebase where routes keep drifting from static to dynamic as features land, and nobody notices until the hosting bill does. What conventions and guardrails would you put in place, and what tradeoffs would you accept?

## Why this drifts in the first place Three properties of the model combine badly at team scale. **It is inferred, not declared.** Nothing in a route says "this one is prerendered". The mode is a consequence of what the code happens to do, so no one owns it. **It is invisible in review.** The pull request that flips a route from static to dynamic often adds one line — an import, or a helper call in a shared header. There is no diff marker for "this now runs on every request for every route in the app". **It is non-local.** The classification is decided by what executes during the render, so a Dynamic API inside a shared package changes routes that never mention it. Blast radius is the whole route, including everything under a shared layout. And the failure mode is not an error. Pages keep working; only cost, cold starts and TTFB move. Anything that only shows up on a graph will be discovered late. ## Guardrail 1 — decide which routes have a contract Not every route needs to be static. Trying to keep all of them static is how you end up fighting the framework. Instead, name the small set where static rendering is load-bearing: the landing pages, the docs, the highest-traffic marketing paths, anything a CDN carries at volume. That list is a product decision, not a technical one, and it should be short enough that people remember it. ## Guardrail 2 — make the guard executable For routes on that list, `export const dynamic = 'error'` converts the contract into a build failure: any Dynamic API or uncached read in the route stops the build and names the call. This is the highest-leverage single line here, because it moves detection from production metrics to the pull request, and it explains itself to whoever hits it. The deliberate refusal is `'force-static'`. It also restores the Static label, but by making `cookies()` and `headers()` return empty values — so the page prerenders while treating every visitor as anonymous. A guard that converts a cost bug into a correctness bug is worse than no guard. ## Guardrail 3 — put the classification in CI The build prints a per-route Static/Dynamic summary. Capture it as a build artifact and diff it against the base branch; fail or warn on any route that moved toward dynamic. This catches the routes not on the protected list, catches framework upgrades that reclassify things by changing defaults, and gives reviewers a fact instead of an intuition. It costs one CI step. ## Guardrail 4 — a convention about where request reads live Most drift arrives through shared code: a header component, a `getUser()` util, an SDK wrapper. The convention that holds up is that request-scoped reads happen in a named, obvious place — a per-route server module, or the page itself — and the values travel downward as props. Shared UI components take a `user` prop; they do not fetch a session. That makes the dynamic dependency visible at the call site and keeps shared components reusable in static routes. The same rule applies to dependency selection: a library whose only server entry point reads `headers()` during render is a library that dictates your rendering mode. That is worth knowing before adoption, not after. ## Guardrail 5 — an agreed pattern for personalization Most drift is one requirement wearing different hats: "show something per user on a page that should be static". Have a house answer so each team does not improvise. The usual choices are a client-side fetch after hydration (static route, brief signed-out flash, extra request), split layouts so only the app section is dynamic (URL-stable via route groups, some duplication), moving the decision into middleware where it is a redirect or rewrite rather than a render input, or adopting Partial Prerendering where the platform and version support it. Picking one as the default and documenting when to deviate is worth more than picking the theoretically best one. ## The tradeoffs I would state plainly - **Ceremony.** Guards and conventions add friction to legitimate dynamic work; sometimes someone must delete a guard on purpose, and that should be an easy, reviewable act rather than a fight. - **Duplication.** Splitting layouts to protect a static section duplicates chrome, and duplicated chrome drifts visually. - **User-visible cost.** Client-side personalization means a flash of the signed-out state, which is fine for a greeting and unacceptable for anything that changes page structure or implies an entitlement. - **Version churn.** Caching and rendering defaults have moved across Next majors, so any convention written against a default needs re-examining at each upgrade. Write conventions against mechanisms — "does this need the incoming request?" — not against defaults. - **Not everything should be static.** The goal is that every dynamic route is dynamic *on purpose*. A team that treats dynamic rendering as failure will reach for `'force-static'`, and that is the one outcome worse than the drift.