Adopting TypeScript Strict Mode in Brownfield Codebases

Flipping `strict: true` in one PR is a morale killer.

We enable flags incrementally — `strictNullChecks` first, then `noImplicitAny`, then the rest — with a tracked burn-down in the ticket backlog.

Production upgrades rarely fail because of framework bugs — they fail when cache assumptions, auth cookies, and CDN headers were never validated together on staging that mirrors real traffic shape.

Before committing to a migration window, align product, infrastructure, and support on rollback criteria. A written go/no-go checklist prevents heroics when metrics drift after deploy.

Boundary types at API edges contain unknown data: validate

with Zod at runtime, export inferred types inward.

Inventory every data fetch path: server components, route handlers, and client-side SWR hooks. Tag each call with expected staleness and document who owns invalidation when upstream data changes.

Middleware and edge handlers deserve the same regression suite as API routes — especially redirects, locale detection, and auth gates that behave differently under bot traffic.

`any` is allowed only in shim files with a ticket link

and expiry date — visible debt beats hidden casts.

Partial prerendering and streaming change how users perceive performance. Measure first meaningful paint separately from time-to-interactive on routes that mix static shells with dynamic holes.

Document boundary decisions in ADRs so the next squad does not collapse dynamic regions back into fully static pages for short-term convenience.

CI fails on new `any` introductions via ESLint and

reports strict coverage percentage weekly.

Staging must replay CDN cache keys, not only origin responses. We clone production cache headers and run synthetic crawls before promoting framework upgrades.

Load tests should include authenticated sessions and cart mutations — anonymous homepage tests alone miss the routes that break under cache policy changes.

Teams that finish strict adoption report fewer production

incidents tied to null access and malformed payloads.

Dashboard cache hit ratio, RSC payload size by route, and error rate per layout segment on one screen. On-call should not hunt across three tools during an incident.

Schedule a 48-hour post-upgrade review with engineering and client stakeholders — capture what surprised you while context is fresh.

The table below summarizes the reference points we review with client stakeholders before sign-off. Use it as a shared vocabulary in sprint planning and release reviews.

Run through this checklist in order — skipping steps because of deadline pressure is how regressions reach production. Assign an owner for each item before you schedule a launch window.