A few years of steadily raising TypeScript strictness on individual projects, one flag at a time, convinced us to stop treating strict mode as something to earn into gradually and make it the non-negotiable default for every new project starting now. The incremental approach had worked well enough on individual projects, but it meant every new project started from a permissive baseline and needed someone to actively decide, and then actively implement, tightening it later, a decision that predictably got deprioritized against more visible feature work often enough that several projects never fully caught up.
The upfront friction for new team members is real but small, and it's far cheaper than retrofitting strictness onto a codebase after a year of loose typing has already let real bugs through. Strict null checks in particular tend to surface a batch of "this could theoretically be undefined here" warnings the moment they're turned on, and on a codebase with a year of history, that batch can be large enough to feel discouraging. Turning strictness on from a project's very first commit means that batch never accumulates in the first place, since every line of code is written under the same rules from day one rather than needing a disruptive retrofit later.
New project templates now ship strict by default with no opt-out, which removes the decision entirely from a project's initial setup rather than leaving it as a checkbox someone might reasonably skip under early deadline pressure when strictness feels like it's slowing down getting an MVP shipped. We were deliberate about removing the opt-out rather than just changing the default, since a default that can be turned off under pressure tends to get turned off under exactly the kind of pressure that makes strictness most valuable in the long run.
We tracked bug reports across a sample of projects built under the new default compared against a similar sample of older projects that had strictness added later, and the pattern matched what we expected going in: projects strict from the start had meaningfully fewer bugs traceable to null or undefined handling reaching production, the exact category of bug strict null checking is specifically designed to catch at compile time rather than runtime.
The team's initial reaction to the new default was mixed, a few engineers who'd built up real fluency working around looser typing found the stricter rules genuinely slowed down their first few weeks on a new strict project. That adjustment period was real, and we didn't pretend it wasn't when rolling this out, but it consistently shortened for each individual engineer as they built familiarity with the patterns strict mode rewards, and it's a one-time cost per engineer rather than a recurring cost the way retrofitting strictness onto an existing codebase would be. A few months in, feedback shifted from complaints about friction to engineers actively requesting the same strict defaults be backported to a couple of older projects that had never fully caught up.