A surprising share of production bugs reduce to the same thing: something was null when the code assumed it was not, or a field arrived as a string when the code expected a number. These are not logic errors. They are shape errors, and shape errors are exactly what a type system exists to prevent.
Pushing types to the source
We run TypeScript in strict mode on every project, and we push the types as close to the data source as we can. The database schema informs the API types, the API types inform the client, and validation at the boundary — we use zod — guarantees that anything crossing into the system matches the shape the types promise.
The pay-off is not fewer bugs in an abstract sense. It is that a whole class of bug stops being possible, and the compiler tells you at the moment you write the mistake rather than the moment a user finds it.
The discipline cost
There is a discipline cost. strict mode is genuinely more annoying in the first week of a project. It is dramatically less annoying in the sixth month, when someone changes a field name and the compiler lists every place that needs updating instead of leaving you to find them in production.
The rule we hold to is simple: if a value can be absent, the type says so — string | null, never a quiet as string. No casting it away because the deadline is close. That cast is a bug with a scheduled delivery date.