Every project we start gets strict mode enabled before the first feature is written. Not because it looks professional in a config file, but because of what it catches.

What strict mode actually buys you

The flag everyone talks about is strictNullChecks. It forces you to acknowledge that a value might be undefined, which is where a huge share of runtime crashes come from:

tstype User = { name: string };

function greet(users: User[], index: number) {
  // Without strict mode this compiles — and crashes at runtime.
  return `Hello ${users[index].name}`;
}

With strict mode on, the compiler refuses. You then have to decide what a missing user means: an empty state, an error, or a guard. That decision is the actual work, and the compiler makes you do it while it is still cheap.

The settings we add on top

Beyond strict, three options do the most work for us:

• noUncheckedIndexedAccess — array and record lookups return T | undefined.
• noUnusedLocals and noUnusedParameters — dead code is removed instead of accumulating.
• noImplicitOverride — subclass overrides are explicit, so renames cannot silently break behaviour.

The first one is the most contentious. It genuinely makes code noisier. It is still worth it: silently missing data is one of the most common causes of the "works on my machine" bug.

Where it does not help

Types describe shapes, not behaviour. They will not tell you that a discount cannot be negative, that a booking cannot end before it starts, or that a payment webhook can arrive twice.

That is what validation schemas and tests are for. We use Zod at the boundaries — HTTP requests, environment variables, API responses — and treat types as the internal contract once data is known to be valid.

The practical argument

Strict mode pays for itself in the first week. Someone enables it later, the build produces three hundred errors, and the ticket gets deprioritised forever. Turning it on at the start costs a few extra keystrokes per file. That trade is easy to make.