Is TypeScript worth it for small projects?

Usually yes. The setup cost is low, and types catch typos, wrong arguments and missing cases while you write code.

Do types replace runtime validation?

No. Types disappear at runtime. Validate data from users, APIs and storage with a schema library, and infer types from the schema.

TypeScript in web projects: practices that pay off

By Ruben Bijker · Published 27 October 2026 · 5 min read

TypeScript pays off when you use it strictly and combine static types with runtime validation at the boundaries of your app. Used loosely, with any everywhere, it adds noise without safety.

Start strict

Enable strict in tsconfig.json from the beginning. Retrofitting strictness later is far more work. Useful extras are noUncheckedIndexedAccess and exactOptionalPropertyTypes, which catch common runtime errors.

Validate at the boundaries

Types describe what you believe the data looks like. Anything entering your app, such as form input, API responses, environment variables and database rows, should be validated at runtime. Libraries such as Zod or Valibot let you define a schema once, then infer the TypeScript type from it, so the two cannot drift apart.

Model your domain with types

Use discriminated unions for states such as loading | success | error, so impossible states cannot be represented.
Prefer string literal unions over loose strings for statuses and roles.
Use branded types for IDs to avoid mixing a user ID with an order ID.
Let the compiler check exhaustive switch statements with a never fallback.

Share types across the stack

In a full-stack TypeScript project, share schemas and types between server and client through a shared package or a framework feature such as server actions or tRPC. A change to the data shape then fails the build rather than production.

Avoid common pitfalls

any and blanket casts. Use unknown and narrow it.
Over-clever generics. If a type needs a paragraph of explanation, simplify it.
Duplicated types. Derive types from schemas, database models or API specs instead of rewriting them.
Ignoring errors with @ts-ignore. Prefer @ts-expect-error with a comment, so it fails when the issue is fixed.

Tooling that completes the picture

Run the type check in CI. Add ESLint with type-aware rules and a formatter. Keep unit tests for logic and a few end-to-end tests for critical flows; types do not replace tests, they reduce the number you need.

Related: API design and AI-assisted development.

Frequently asked questions

Is TypeScript worth it for small projects?: Usually yes. The setup cost is low, and types catch typos, wrong arguments and missing cases while you write code.
Do types replace runtime validation?: No. Types disappear at runtime. Validate data from users, APIs and storage with a schema library, and infer types from the schema.

Have a project in mind?

Tell me briefly what you need. You get an answer from me, not from a sales team.

Get in touch

API design: REST, GraphQL or tRPC?
How REST, GraphQL and tRPC differ, when each fits, and the design habits (versioning, errors, pagination, auth) that matter more than the protocol.
SSR, SSG, ISR and CSR: choosing a rendering strategy
What server-side rendering, static generation, incremental regeneration and client-side rendering actually do, and how to pick the right one per page.