TypeScript is JavaScript with a type system layered on top. It catches a whole category of bug — a missing field, a wrong shape, a value that can be null — while the code is being written rather than after a customer finds it. We use it on every JavaScript project without exception.
What is TypeScript?
JavaScript does not check what kind of thing a variable holds. If a function expects a customer object and receives the string "undefined", JavaScript will happily carry on and fail three functions later, somewhere unrelated, at 2am. That is the single most common category of production bug in web software.
TypeScript adds a description of what each thing is supposed to be, checks it while you write, and then compiles away to ordinary JavaScript. Nothing extra ships to the browser. The types exist for the people and the tooling, not for the runtime.
The practical effect is that the editor knows what your code means. It autocompletes real field names, refuses to let you misspell one, and tells you immediately which twelve places break when you rename something — which is what makes a large codebase safe to change at all.
When we choose TypeScript
Always. There is no project size at which we recommend plain JavaScript, and that is not dogma — it is that the cost of TypeScript is a few hours of setup and the cost of not having it is paid in production, repeatedly, by whoever inherits the code.
It matters most on the projects clients care most about: anything with a payment, anything with a permission check, anything where two systems exchange data. Those are exactly the places where a field quietly changing shape causes a real loss, and exactly the places TypeScript catches it at the keyboard.
It also matters when we hand a project over. A typed codebase tells your next developer what everything is without them having to read every function. That is the difference between a handover and an archaeology project.
When we do not use TypeScript
The honest exception is a genuinely throwaway script — a one-off data migration, a scratch prototype nobody will keep. Adding a build step there is ceremony.
The other real cost is a team that has never used it. TypeScript makes a JavaScript developer slower for about two weeks. If a client's in-house team is plain-JavaScript and has no appetite to learn, forcing it on them produces code full of any, which is the worst of both worlds: the build step without the safety. In that case we say so and build in plain JavaScript with stricter linting instead.
What we build with TypeScript
Typed API contracts between front and back
The single highest-value use. The shape of every API response is defined once and shared, so a backend change that removes a field breaks the build rather than breaking the screen for a customer. This is where most integration bugs would otherwise live.
Large front-ends that stay changeable
On an application with a hundred screens, the question is never "can we build it" but "can we still change it in year three". Types make a rename safe and a refactor possible, which is what keeps a codebase from calcifying into something nobody dares touch.
Shared logic between web and mobile
When a project has both a web app and a React Native app, the validation rules, the pricing logic and the API layer are written once and typed once. Both platforms then get the same behaviour by construction rather than by two teams remembering to match.
Shared types between front end and API
One definition of what an order looks like, used by both sides. Rename a field and the build tells you every place that has to change — which is the single most useful thing types do on a real project.
How we ship TypeScript projects
Strict mode on from the first commit. Turning it on later means fixing hundreds of errors at once, which nobody does, so the project quietly stays half-typed forever.
any is treated as a code smell in review. It switches the type checker off for that value, and a codebase with any scattered through it has the build cost of TypeScript and none of the benefit.
Types are generated from the source of truth wherever possible — from the database schema, from the API definition — rather than hand-written in two places that drift apart.
What TypeScript costs you
It adds a compile step, which means a slower feedback loop while developing and one more thing that can fail in CI. On a modern toolchain that is seconds, not minutes, but it is not nothing.
It also cannot check what happens at the boundary. Data arriving from an API is whatever the server actually sent, regardless of what the type says it should be. We validate at those boundaries at runtime rather than trusting the type, because a type is a promise and the network does not keep promises.
TypeScript questions we get asked
No. It compiles away entirely — the browser receives ordinary JavaScript and never sees a type. The only cost is at build time, on our machines, not on your visitors'.
Yes, with about two weeks of adjustment. TypeScript is JavaScript — every valid JavaScript file is a valid TypeScript file. Most developers describe the transition as annoying for a fortnight and then unthinkable to go back from.
Slightly at the start and considerably less later. The first week costs a little in type definitions; every week after that it pays back in bugs caught at build time rather than by a customer. On anything past a few weeks of work it is comfortably net positive.
Yes, file by file — that is a deliberate design property. We usually start with the parts that break most often, which is normally anything touching money, dates or API responses, and leave stable code alone until it needs changing anyway.