TypeScript: baseline, not an option
2 errors — caught at compile time, not in production
Some teams treat TypeScript as optional—a choice you make for large projects or when you have time. We treat it as the minimum viable starting point, the same way you wouldn't ship a project without version control. The question isn't whether to use it; it's how strictly to use it.
The payoff is front-loaded. Type errors caught at compile time cost minutes to fix. The same error caught in production costs hours of debugging, a client call, a hotfix deploy, and user trust. Strict TypeScript with no-any rules converts a class of runtime failures into build failures. The CI pipeline rejects the problem before it reaches staging.
It also changes how teams collaborate. When a function has typed inputs and outputs, you can read it without running it. Refactors become safer because the compiler traces every callsite. Adding a field to a shared type immediately surfaces everywhere that field needs handling—not in code review, but in the editor, in real time.
We enforce strict mode across every project: noImplicitAny, strictNullChecks, exactOptionalPropertyTypes. It adds friction at the beginning. It removes friction permanently after that. The clients who've worked with us after a TypeScript-lax team notice the difference in delivery confidence immediately.