We write TypeScript everywhere — frontend, backend, build scripts, infrastructure glue. Not because it is fashionable, but because the alternative is discovering the shape of your own data from a production error.
Strict from the first commit
Turning strict mode on later is a migration. Turning it on at the start is free.
So it is on, any needs a comment explaining itself, and the build fails on type
errors rather than warning about them into a log nobody reads.
One contract, two ends
The type that describes an API response is generated from the schema and shared by the server that produces it and the client that consumes it. Rename a field and both ends stop compiling in the same second. That is the whole value: the mistake becomes impossible rather than merely discouraged.
What types are good at
They are excellent at structure — what exists, what is optional, which states can
coexist. They are useless at truth: a string that says it is an email address
still needs validating at the edge. We parse and validate incoming data at the
boundary and trust it afterwards.
Where it pays off
The payoff is not fewer bugs on launch day. It is the sixth month, when a new developer renames something across forty files and the compiler tells them exactly which nine of them were wrong. That is the number that decides what maintenance costs.
Practical limits
Types slow down a genuine prototype, and we will say so if that is what you are paying for. On anything meant to live past a quarter, the trade is one-sided.
Related: React, Node.js, and the review discipline described under QA and testing.