Most teams use TypeScript as JavaScript with a few annotations, which leaves most of its value untapped. Used well, the type system eliminates entire categories of runtime bugs at compile time and makes a large codebase safe to change. These are the patterns that deliver the most maintainability, and they pay off most in the kind of long-lived applications we build through our web engineering work.
Discriminated unions for state
Application state is full of cases that should be mutually exclusive: loading, loaded, error. Modelling these as a discriminated union, where a shared tag field distinguishes each case, lets the compiler force you to handle every possibility and prevents impossible states like loaded-but-also-error. This single pattern removes a huge class of "cannot read property of undefined" bugs by making the bad states unrepresentable.
Branded types for values that look alike
A user id and an order id are both strings, and nothing stops you from passing one where the other is expected. Branded types attach a compile-time tag to a primitive so the type system treats them as distinct, catching mix-ups that would otherwise be silent runtime bugs. They are invaluable for ids, validated values, and units.
Lean on inference, annotate boundaries
Good TypeScript is not covered in explicit type annotations. Let inference do the work inside functions, and reserve explicit types for the boundaries: function signatures, public APIs, and module exports. This keeps code readable while still giving you strong guarantees where they matter, and it makes refactoring safer because the compiler propagates changes through inferred types.
Make illegal states unrepresentable
The overarching principle behind these patterns is to design types so that invalid combinations simply cannot be constructed. If two fields must either both be present or both absent, model them as a single optional object rather than two independent optionals. The more the types encode your real rules, the fewer runtime checks and defensive branches you need.
Template literal types for string contracts
Template literal types let you describe the shape of strings, such as route patterns or event names, at the type level. This catches typos in things that used to be stringly-typed and only failed at runtime, turning a class of silent mistakes into compile errors.
Types are documentation that cannot rot
Beyond catching bugs, the underrated benefit of using the type system well is that the types become living documentation. A function signature that precisely describes what it accepts and returns tells the next engineer exactly how to use it, and unlike a comment it can never drift out of sync with the code, because the compiler enforces it. A discriminated union that enumerates every state of a feature is a clearer specification of that feature than any wiki page. This is why investing in good types pays off most on long-lived codebases and larger teams, where the people changing the code are often not the people who wrote it. The types carry the intent forward. Comments lie eventually; well-designed types cannot, which makes them the most reliable form of documentation a codebase can have.
Use the strictest configuration
Enable strict mode and resist the urge to reach for escape hatches. Every use of the any type or a non-null assertion is a hole in the guarantees you are paying for. The discipline of keeping the codebase genuinely strict is what makes the type system trustworthy, and it is the kind of standard a strong code review culture enforces. These patterns also shine in a Next.js application, where types flow across the server and client boundary.