Skip to content
Custom Theme

TypeScript strictness pays for itself by month three

By Custom Theme2 min read
TypeScriptCode quality

TypeScript's strict mode is expensive. You write more code. You refactor data flows to match type signatures. You argue with the compiler.

We thought the strictness was worth the cost. Three months later, we had half as many bug reports. We were right.

What strict mode catches

In loose mode, TypeScript allows any, implicit nulls, and unchecked function parameters. These are escape hatches for "I do not know the type yet." In practice, they become places where bugs hide.

Strict mode forces you to name every type:

// loose: this is allowed
const fetch = (id) => axios.get(`/api/${id}`);

// strict: types are required
const fetch = (id: string): Promise<User> => axios.get(`/api/${id}`);

That second signature is more work to write. But it is also a contract. Callers know exactly what they are passing and what they are getting. Refactor the response shape and TypeScript tells you everywhere it broke.

The bugs it prevents

We documented every compiler error for a month. Most fell into these categories:

  1. Null reference errors: passing undefined where a value is required. TypeScript catches it immediately. The alternative is a runtime crash.

  2. Response shape mismatches: an API changes response structure and the client still tries to access the old fields. Strict mode catches it at compile time.

  3. State synchronization bugs: React state and server state get out of sync because the component does not type-check its assumptions about shape. Strict mode forces the assumptions explicit.

The cost

Strict mode added about three weeks of refactoring per template, the first time. It is not a small cost.

But the payoff is that new features cost less. Because the data flow is type-safe end-to-end, you can refactor confidently. You can rename fields without fear of missing call sites. You can extract logic without worrying that a null check was hiding in the wrinkled code.

When to enable it

If your codebase is in TypeScript already, enable strict mode for new files and gradually migrate old files as you touch them. The all-at-once approach is a month of refactoring hell.

If you are starting a new project, start with strict. The cost upfront is less than retrofitting it later.

If you are shipping a prototype and you expect to throw it away, strict mode is overkill. Use it when you are committing to maintaining the code for years.

We committed. Three months in, the reduction in bugs was obvious. Six months in, we could not imagine going back.