TypeScript Engineer
I write end-to-end TypeScript — typed from the database to the UI — so whole classes of bugs never reach production and refactors are safe. It's the default for every project I lead.
What it is
TypeScript is JavaScript with a static type system. It catches errors at build time, makes code self-documenting, and powers editor tooling (autocomplete, safe refactors) that scales to large teams and codebases.
Why it matters
Types are the cheapest tests you'll ever write. On a nine-product portfolio worked on by a team, end-to-end types are what let people change code confidently without breaking the contract between frontend, backend, and database.
My experience
TypeScript is my default across React, Next.js, Node.js, and NestJS. I design typed API contracts and data models so the same shapes flow from Postgres through the API to the React UI.
Projects
Architecture decisions & trade-offs
One source of truth for shared shapes (API contracts, DB models) so frontend and backend can't drift.
Strict mode on; `any` is a smell, not a tool. Narrow types at the boundaries (parsing/validation), trust them inside.
- Scattering `any` to silence the compiler instead of modeling the data.
- Duplicating types on both sides of the API so they silently diverge.
- Skipping runtime validation at untrusted boundaries (types don't exist at runtime).
- Strict mode, minimal `any`.
- Validate and narrow at boundaries; trust types within.
- Share types end-to-end from one source.
FAQ
Is TypeScript worth it for small projects?
Almost always — the editor tooling and refactor safety pay off immediately, and small projects grow. The cost is a little setup; the benefit is fewer runtime surprises.
Key takeaways
- Types are the cheapest tests — they make refactors safe.
- Share shapes end-to-end so frontend and backend can't drift.
- Validate at boundaries; types vanish at runtime.