A team has made every route in their Next.js App Router app render on each request because it is simpler and always fresh. As the engineer leading the app, how do you evaluate that default and decide which routes to pull back to static or revalidated rendering?

## Start by conceding the good part A lead who opens with "dynamic everywhere is wrong" loses the room. It has genuine advantages: one mental model, no cache-invalidation class of bug, and no possibility of serving a personalized page to the wrong person. Those are the failure modes that produce incidents, and the team chose to eliminate them. The correct critique is narrower — the choice was made *by default rather than by decision*, and its costs are invisible because nobody has priced them. ## What the default actually costs Four axes, and it helps to name them separately because they fail differently. **Cost.** Server work scales one-to-one with page views. A route serving identical HTML to a million visitors runs a million renders. Whether that shows up as compute spend or as capacity you must keep provisioned, it is a line item that grows with success. **Latency.** A per-request render cannot finish before the slowest thing it awaits. Every upstream dependency is now on the critical path of every visit, and time to first byte is bounded below by the p99 of the worst call. Prerendered output moved those calls off the request path entirely. **Resilience.** This is the argument that lands hardest and gets raised least. When the product API is down, a route with stored output keeps serving the last good page; a per-request route serves an error. Rendering mode is therefore a availability decision for the pages that matter most — the ones you would rather show slightly stale than not at all. **Elasticity.** Traffic spikes are the case where the two diverge most sharply. A campaign, a link from a big account, a crawler sweep — cached output absorbs it, per-request rendering forwards the whole shape of it to your backend. ## The inventory I would build a small table before touching any code, with one row per route and three columns. 1. **Does the output depend on the requester?** Signed-in state, cookies, geo, search params. If yes, the route stays dynamic — this is not negotiable and is where the team's instinct was right. 2. **What staleness is tolerable, in seconds?** Ask product, not engineering. Engineers answer "as fresh as possible" because staleness has no cost to them; product owners can tell you that a marketing page may be an hour old and a stock indicator may not be five seconds old. 3. **What share of traffic does it carry?** This orders the work. Converting a route nobody visits changes nothing. The rows that are request-independent, staleness-tolerant and high-traffic are the conversion list, in that order. Usually it is a handful of routes — a landing page, a catalogue index, a docs or article tree — carrying a large fraction of total volume. ## Sequencing and proof Convert the top one or two first, and instrument it. What I want to see: origin request volume for that path dropping toward zero, time to first byte losing its long tail, and no increase in complaints about stale content. Then rerun a synthetic upstream failure and confirm the converted route still serves while the dynamic ones degrade. That evidence, on a route the team cares about, does more to settle the argument than any amount of reasoning about theory. Where the freshness tolerance is short but nonzero, revalidated prerendering is the middle ground — you keep cached economics and bound how old the page gets. Where the tolerance is genuinely near zero and the page is still identical for everyone, dynamic rendering is the right answer and should be recorded as a decision, not an accident. ## What I would institutionalize The durable outcome is not a set of converted routes; it is that rendering mode becomes an explicit property of each surface. Concretely: a stated staleness budget per route in the same place the team documents ownership, a review question for new routes asking which mode and why, and a check on the build output so a route silently flipping to dynamic is noticed at review time rather than in a bill. ## Where I would stop I would resist converting the long tail. The cost curve is dominated by the top routes, and each conversion adds an invalidation path somebody has to maintain. Leaving low-traffic and genuinely request-dependent routes dynamic keeps the mental model simple where it does not cost anything — which is, in the end, agreeing with the team's original instinct in the places where it was right.