TypeScript: why we write your website and software in it
TypeScript adds checking to JavaScript so many bugs are caught before shipping. What it is, what it costs, and why it protects your budget.
The short answer
TypeScript is JavaScript with a checking layer on top. The developer writes down what shape data has, for example that a customer has a name, an email and an optional phone number, and a checker verifies, before anything runs, that every piece of code uses that data correctly. A field that might be missing, a number where text was expected, a change in one place that breaks another: all caught on the developer’s screen rather than on a visitor’s. It compiles into ordinary JavaScript, so the visitor sees no difference and pays no cost.
We write every website and every piece of software in it, because the bugs it prevents are exactly the ones that cost clients money after launch.
The bugs it catches
| Everyday bug | Without TypeScript | With TypeScript |
|---|---|---|
| A field is missing on some records | Page crashes for those visitors | Checker demands the missing case be handled |
| A function is called with the wrong kind of value | Silent wrong result or a crash | Refused at the desk |
| A data structure changes in one place | Other places break, discovered by users | Every dependent place is listed instantly |
| An external service changes its response | Subtle breakage weeks later | Mismatch at the boundary is flagged |
| A typo in a property name | Undefined value, hard to trace | Immediate error |
What it costs, honestly
- A little more writing at the start, describing shapes and handling edge cases the checker insists on. This is exactly the work that would otherwise be done as debugging later.
- A build step, which modern frameworks include anyway.
- Discipline at the boundaries: data arriving from outside, a form, an API, a file, must be validated before it is trusted. TypeScript makes this explicit rather than optional.
Why it protects your budget
Software is changed far more often than it is written. Every change to untyped code is a small gamble that nothing elsewhere depended on what was changed. Typed code turns that gamble into a list: change the definition, and every affected place is shown before the change ships. Over years of a site or an app being maintained, that is the difference between predictable change budgets and recurring firefighting. It is also why a new developer can take over typed code in days: the types tell them what everything expects.
What this means for you
You will never see TypeScript, and that is the point. What you see is fewer production bugs, changes that do not break unrelated features, and a codebase a successor can take over. It is one of the least visible and most valuable choices in a project, and one we make without exception.
Frequently asked questions
Is TypeScript slower for visitors?
No. TypeScript is checked and then compiled into plain JavaScript before the site is built. The browser receives ordinary JavaScript, identical in speed. The checking happens on the developer's machine and in the build pipeline, never in the visitor's browser.
Does it make projects more expensive?
Slightly more writing at the start, and noticeably less debugging and firefighting afterwards. On anything that will be changed over the years, which is every business site and every piece of software, it pays for itself many times over. We would not build without it.
Can other developers work on TypeScript code?
More easily than on untyped code. The types are documentation that cannot go stale: they tell a new developer exactly what every function expects and returns, and the checker tells them immediately when a change breaks something elsewhere.
Sources
- TypeScript documentation (accessed 2026-09-11)