← All articles
Stack·3 min read

Why I keep returning to TypeScript across the stack

Shared types between NestJS, Next.js, and React Native, and how one language reduces coordination cost when you are building product end to end.

typescriptnestjsnextjsreact-native

When you build alone or in a small team, context switching is the tax you pay for wearing every hat. TypeScript does not remove that tax, but it lowers it: the same mental model travels from API contracts to UI forms to mobile screens.

I like NestJS for clear modules and testable services. I like Next.js when the web product needs routing, server concerns, and a path to production that is not a science project. I like React Native when the mobile app should speak the same product language, not become a separate company inside the company.

What shared typing buys you

  • Fewer “stringly typed” API surprises between client and server.
  • Refactors that fail in CI instead of in a customer’s session.
  • Onboarding that teaches one type system, not three dialects of guesswork.

None of this is ideology. If a domain needed another tool tomorrow, I would use it. Until then, TypeScript remains the shortest path between idea and dependable software for the products I ship.

Key takeaways

What to remember

  • Shared types cut coordination tax.
  • Nest + Next + RN keep one product language.
  • Depth beats logo collecting.
Tubonibo Williams

Written by

Tubonibo Williams

Isaac · Full-stack engineer

Full-stack engineer. I build products like Djengo end to end , architecture, delivery, and the human side of shipping under pressure. Open to roles and collaborations that value operable software.

More from the archive

Related articles