Technology
TypeScript
We use TypeScript in strict mode across front end, back end and tooling, with types modelling the domain rather than decorating it.
Types as design, not annotation
A type system earns its cost when it makes invalid states unrepresentable — a discriminated union that forces you to handle the loading case, not an `any` with a comment.
We model domains in the type system so the compiler catches the class of bug that would otherwise reach a code review, and so refactoring a widely used shape is a mechanical exercise rather than an archaeology project.
Practice
How we use it
Strict mode everywhere
No implicit any, exhaustive switch handling, and no escape hatches without a comment explaining the trade.
Domain modelling
Discriminated unions and branded types so invalid combinations fail to compile rather than fail in production.
End-to-end type safety
Shared types or generated clients between server and client, so an API change breaks the build rather than the browser.
Runtime validation at the edge
Schema validation where data enters the system, because a type is a compile-time promise and the network makes none.
Judgement
When TypeScript is the right call
And when it is not. A technology page that only lists strengths is a brochure.
Reach for it when
- Any JavaScript codebase expected to live beyond a quarter
- Teams larger than two, where types are the cheapest documentation
- Domains with meaningful invalid states — money, permissions, workflow
Look elsewhere when
- A genuinely throwaway script
- Where the team has no appetite for the build step and the code is trivial
Sectors
Where we run it
Also relevant