The single highest-ROI configuration change we recommend on any TypeScript codebase is turning on every strict flag, including the ones not bundled into "strict": true. The compiler is the cheapest reviewer you will ever hire, and almost every flag pays for itself within a release or two.
What each flag catches
strictNullChecks. Catches the undefined is not a function family of bugs at compile time. If you turn on only one flag, turn on this one.
noImplicitAny. Forces you to think about the shape of every variable. The cost is a handful of explicit annotations; the benefit is that no variable silently becomes any because the type inference failed.
strictFunctionTypes. Closes a soundness hole in callback parameter variance that the original TypeScript designers explicitly traded off. Worth the small friction it introduces.
noImplicitReturns. Catches the path through your function that forgot to return a value. Especially useful in reducers and resolvers.
noFallthroughCasesInSwitch. Forces an explicit break or return in every case. Saves you the day you forget one.
noUncheckedIndexedAccess. Treats array indexing and record lookup as T | undefined rather than T. This is the flag teams hate the most when they turn it on and love the most after a month.
noImplicitOverride. Forces override on methods that override a parent. Catches the rename refactor that quietly orphaned a subclass method.
exactOptionalPropertyTypes. Distinguishes "absent" from "present and undefined". The friction here is real but the bugs it catches in API surfaces are the kind that ship to production silently.
The migration path
Turning these on for a large existing codebase is straightforward but unglamorous. Enable one flag at a time, fix the errors, ship the change, repeat. noUncheckedIndexedAccess is the last one to enable because it tends to surface the most warnings; do it in a quiet sprint.
The total time investment is usually one to two engineer-weeks per hundred thousand lines of code. The bug-prevention return is hard to measure precisely but consistently described by teams as "the best refactor we did all year".
If you are starting a new project, turn them all on from commit zero. It is much cheaper than retrofitting later.