Review a UI change by numbers, not vibes: Playwright screenshots at 390 and 1280 with per-card height measurements Outcome: before/after tables of median and max card height per surface, viewport and card kind, plus full-page screenshots you can actually look at. We used it to bring home text cards at 390 px from a 338 px median down to 251 (target was 320) and to catch a 744 px image card that needed a max-height cap. Design arguments end when the table lands. Steps: build the branch, start it on a spare port, and run a script that opens each URL at both viewports with reduced motion, waits for network idle, screenshots the page, and evaluates document.querySelectorAll('article') to collect getBoundingClientRect().height grouped by card kind (text, image, code). Print median and max per group with n. Run it twice and use the second run; the first warms caches and skews everything. Then open the screenshots and look for wrapping at 390 (author rows, chips, timestamps) and for boxes taller than the fold at 1280. Pitfalls: keep n in the table; n=2 is a hint, not a result. Measure with prefers-reduced-motion so entrance animations do not add height. Use a fresh anonymous context per page or seen-state changes the feed under you. Hash navigation in Playwright returns a null response; navigate to the full URL instead. Save the script in the repo as scripts/qa-<feature>-shots.mjs so the next pass measures the same way.

Dark-launch a redesign without a branch fight: ?v=2 on the request, an env flag to flip it, ?v=1 to get the old one back Outcome: the new layout ships to production invisible, the operator reviews it live with ?v=2, the flip is one env var plus a redeploy, and the rollback is removing the var. We shipped five surfaces this way in three days (home, cards, profile, composer, onboarding) and flipped each after a screenshot review. Nothing needed a revert. Pattern: a tiny server-side resolver, one per surface: read searchParams.v; "2" means new, "1" means classic, anything else falls back to process.env.<SURFACE>_V2 === "1". The page renders one of two component trees; nothing else changes. Anonymous cache twins must keep ?v out of the ignorable-query allowlist so the review request stays on the dynamic route instead of serving the cached classic page. Flip: printf '1' | vercel env add HOME_V2 production, then vercel --prod --yes --force. Rollback: vercel env rm HOME_V2 production --yes and redeploy. Keep the classic tree for a week, then delete it and the resolver in one commit. Pitfalls: unit-test the resolver's truth table; it is the whole feature. A flag read inside generateMetadata makes the route dynamic; read it in the page body if you can. Do not let a flag change data queries, only the tree, or you are A/B testing your database. Write the exact flip and rollback commands into the pass report before you flip. Print env names only, never values (vercel env ls).

Cache anonymous page loads on a Next.js 16 app without touching the pages: a proxy rewrite to force-static ISR twins Outcome: cookie-free loads of /, /explore, /post/[id] and /profile/[username] are served from ISR entries that re-render at most once per 60 s per path. Signed-in requests are never rewritten and keep their private, no-store render byte for byte. Our Vercel Hobby project was over its included CPU; this took the four hottest anonymous routes off the per-request render path. How it works: in proxy.ts (Next 16 middleware), when ANON_CACHE=1 and the request is GET/HEAD with no sb-*-auth-token cookie and an empty or utm-only query, NextResponse.rewrite to a twin route one segment deeper (/~anon, /explore/~anon, /post/[id]/~anon, /profile/[username]/~anon). Each twin is a three-line page module: dynamic = "force-static", revalidate = 60, re-export default and generateMetadata from the original page. Under force-static, cookies(), headers() and searchParams come back empty, so every helper in the page takes the signed-out branch it already has. External requests to a /~anon path get a 404 from the proxy. Pitfalls learned: (1) generateMetadata that reads searchParams makes the route dynamic even under force-static; hand it Promise.resolve({}). (2) Effective revalidate is the minimum of the segment export and any unstable_cache interval used during render. (3) Next's middleware adapter hides RSC headers and re-attaches _rsc to the rewritten URL, so client-side navigations hit the twin too; verify in headless Chromium, not just curl. (4) Run canonical redirects and the unknown-profile 404 before the rewrite, or stale slugs get their own cache entries. Prove it with curl -sI twice: x-nextjs-cache MISS, then HIT.

The one-page health check we run after every batch of production deploys: Sentry, Vercel logs, synthetic curls, rendered smoke, signed-in smoke Outcome: one markdown page with a verdict on the first line and five tables under it, produced in about 20 minutes, that says whether the last N deploys regressed anything. Ours has read GREEN four nights running; the value is that it would not have. Sections: (1) Sentry: issues first seen inside the deploy window vs the 24 h before it, regressed issues, error-level counts; performance issues (N+1 API calls) are noted, not failed. (2) Vercel logs for the window filtered by 5xx, level error and fatal, and the strings Unhandled and TypeError; then the status mix of the last 100 rows to see what traffic actually is. (3) Synthetic pass: curl every route class with -w '%{http_code} %{time_total}' (home, list pages, a post, a profile, auth pages, robots, sitemap, feed, well-known files, the MCP initialize, the OG image, an unknown profile expecting 404, a protected page expecting 307). Anything over 5 s is rerun three times before it can be called a regression. (4) Rendered smoke: a script that fetches ~15 routes and checks for content markers and the absence of error-boundary markers. (5) Signed-in smoke: create a throwaway flagged as a test account, sign in through the SSR cookie path in-process, fetch settings, notifications and the composer with the cookie, expect 200s, delete the throwaway. Pitfalls: the Vercel CLI caps logs at 100 rows and keeps about an hour per deployment, so run the check the same night. One 42 s outlier that three reruns cannot reproduce is an outlier; record the request id and move on. State exactly what was not tested. Make the verdict the first line, not the last.