Why we build in TypeScript

If you've hired anyone to build software in the last few years, you've probably heard the word TypeScript. Maybe a developer told you the project "should be in TypeScript" and you nodded along. Here's what that actually means, why we default to it for almost everything we build, and why it matters to you as the person paying the invoice.

What TypeScript actually is

JavaScript is the language that runs in every web browser and powers a huge share of servers through Node.js. TypeScript is JavaScript with one big addition: types. A type is a label that says what kind of thing a piece of data is. This variable is a number. This function takes a customer record and returns an invoice. That field can be empty, so check it before you use it.

Plain JavaScript doesn't enforce any of that. You can pass a customer name where the code expected a customer ID, and JavaScript will happily run it. The bug shows up later, at runtime, usually in front of a user. TypeScript catches it before the code ever runs. The compiler reads the whole project and flags every place where the pieces don't fit together.

The important part: TypeScript compiles down to plain JavaScript. It runs everywhere JavaScript runs. You're not buying into some exotic platform. You're adding a safety layer on top of the most widely used language in the world.

Types catch the bugs tests miss

People sometimes argue that good tests make types unnecessary. We've never seen that hold up on a real project. Tests check the cases someone thought to write. Types check every line, every time, automatically.

The bugs that bite hardest in business software are boring ones. A field that's sometimes null. A date stored as a string in one place and a Date object in another. An API response that changed shape and nobody noticed until the reports came out wrong. Tests rarely cover those because nobody imagined them. The type checker doesn't have to imagine anything. It knows the shape of every piece of data and complains the moment two shapes disagree.

In practice, a whole category of production bugs just disappears. Not all bugs. Logic errors still exist, and you still need tests for those. But the "undefined is not a function" class of failure, the one that pages someone at 2 a.m., mostly goes away.

Why this matters to your budget

You're not paying for TypeScript because it's trendy. You're paying for what it does to the cost curve over time.

• Changes get cheaper. When we rename a field or change how invoices are calculated, the compiler lists every single place in the codebase that needs updating. In plain JavaScript, we'd find those places by hunting, or worse, by users finding them for us.
• Handoffs get safer. Someday a different developer will touch this code. Maybe us in two years, maybe someone else. Types are documentation that can't go stale, because the compiler enforces them. A new developer can see exactly what every function expects.
• Fewer emergency calls. Bugs caught at compile time cost minutes. Bugs caught in production cost hours of diagnosis plus whatever the outage cost your business.

Where we skip it

We're not religious about this. A ten-line script that moves files or pokes an API once a day doesn't need a compiler. For quick automation we'll often reach for plain JavaScript or Python and get it done in an afternoon.

The line for us is roughly this: if the code will live longer than a month, if more than one person will ever read it, or if it handles money or customer data, it gets types. Anything past a throwaway script, we build in TypeScript. The setup cost is an hour. The payoff runs for the life of the project.

How to know it's done right

If someone builds TypeScript software for you, a few questions tell you whether they used it properly or just checked a box:

• Ask about "strict mode." TypeScript has a strictness setting. With it off, you get maybe a third of the benefit. Any serious shop turns it on from day one. The honest answer here is "yes, strict is on."
• Ask how often they use "any." The any type is an escape hatch that turns the checker off for a piece of data. A little is normal at the edges. A codebase full of it is JavaScript wearing a costume.
• Ask if the build fails on type errors. It should. If type errors are warnings that everyone ignores, the safety layer isn't doing anything.

You don't need to understand the answers deeply. You just need to hear confident, specific answers instead of hand-waving. We build in TypeScript by default because it makes the software cheaper to own, not just cheaper to ship. That's the standard we'd want if we were the ones writing the check.