TypeScript Mandatory: How Type Safety Saved Us in Production
Three years ago our frontend was pure JavaScript. Then a production bug cost us two days of work: an undefined field silently passing through 4 React components before breaking everything. From that day, TypeScript became mandatory on every i3k project. Here's why we'd never go back.
The Bug That Changed Everything: From JavaScript to TypeScript
It was a Friday afternoon — of course. A CRM81 client reports that the deal list won't load anymore. We open the console: "Cannot read property 'amount' of undefined". The problem? An API endpoint had changed its response structure: the deals field had become deals_list, and nobody had updated the frontend. In JavaScript, code doesn't complain if you access a non-existent field — it simply returns undefined and moves on. That undefined traveled through four React components before causing a crash in the component trying to call .toFixed(2) on undefined. With TypeScript, that bug would never have reached production. The response object type would have generated a compile-time error the exact moment someone changed the API interface. We didn't even need a test — the compiler would have blocked the deploy. The migration started the following Monday. We decided against the big bang approach (renaming all .js to .ts at once), opting for an incremental strategy: every new file had to be .tsx/.ts, and every file touched for bugfix or feature was converted. In 4 months, 80% of CRM81's codebase was TypeScript. Today we're at 100% across all projects.
Type Safety in the Real World: Patterns We Use Every Day
TypeScript's value isn't just catching undefined. Here are the patterns that saved us the most time at i3k. First: discriminated unions for application states. In LetsAI, an AI job can be in "pending", "processing", "completed", or "failed" state. With TypeScript, each state has its own type with different fields — a completed job has a result field, a failed job has an error field, and the compiler forces you to handle all cases. No more "result is undefined because the job actually failed". Second: strict mode without compromise. In our tsconfig.json we have strict: true, noUncheckedIndexedAccess: true, and exactOptionalPropertyTypes: true. Is it strict? Yes. Does it force you to handle every possible null and undefined? Yes. But since the day we enabled it, null-related production bugs dropped 85%. A number that justifies any complaints about extra type annotations. Third: generics for APIs. We have a typed fetch wrapper: apiClient.get<DealResponse>('/api/deals'). The return type is automatically DealResponse, and if the endpoint changes structure, the compiler flags every point in the code using that response. In a project with 200+ API calls, this eliminated an entire class of bugs. Fourth: types as living documentation. TypeScript interfaces are the most up-to-date documentation we have. When a new developer joins the team, they don't need to ask "what fields does a Deal have?" — they look at the interface and know everything. Interfaces that automatically update with the code, unlike comments that age.
The Impact on DX and Productivity: Real Numbers
After the complete migration to TypeScript across all i3k projects (i3k.eu, CRM81, LetsAI, RAG Enterprise PRO frontend), we measured the impact on team productivity. The results exceeded expectations. Production bugs related to types/null/undefined: from 12 per month to fewer than 2. Average onboarding time for new developers: from 3 weeks to 10 days, because types guide code understanding. Code review time: reduced by 30%, because the compiler catches trivial issues before they reach review. Refactoring speed: 3x faster. Renaming a React prop or changing an object structure? The compiler instantly shows you every point to update. The only real cost is compilation time. Our largest project (CRM81, ~800 TypeScript files) takes 18 seconds for a full type-check. But with incremental compilation enabled, checks during development are under 2 seconds. A negligible price for the safety it provides. The advice we give to anyone considering migration: start with strict: false and enable strict options one at a time. Start with the most critical files (API layer, data models, shared components) and leave the less important files for last. In 3-4 months you'll be full TypeScript without ever blocking feature development.
Related Services
See how we apply these technologies in our enterprise projects.
Interested?
Contact us to receive a personalized quote.
Securvita S.r.l. — i3k.eu