TypeScript: baseline, not an option
2 errors — caught at compile time, not in production
ypeScript is JavaScript with type annotations — descriptions of what kind of data a variable holds or a function expects. When you run a build, TypeScript checks that all these descriptions match the actual code. If something doesn't match, the build fails. This sounds like friction, but it's the same kind of friction that makes a car's seatbelt annoying to put on and catastrophic not to.
The economics are straightforward. A type error caught during compilation takes a few minutes to fix — you see the red underline in the editor, understand immediately what's wrong, and fix it. The same error in production means a support ticket, a debugging session, a hotfix deploy, and lost user trust. Teams that treat TypeScript as optional are essentially choosing to delay their bug-fixing costs rather than eliminate them.
Beyond catching errors, TypeScript changes how teams work together. When a function has typed inputs and outputs, you understand it without running it. When you rename a property, the compiler shows every place that needs updating — not in code review the next morning, but right now in the editor. When a new developer joins, the types serve as living documentation: what does this function need, what does it return, what can go wrong.
We enforce strict mode across every project: noImplicitAny, strictNullChecks, exactOptionalPropertyTypes. The setup adds a bit of friction in the first day. It removes friction permanently after that. Clients who come to us from teams that treated TypeScript as optional notice the difference immediately — not in the code itself, but in the confidence of every deployment.