TypeScript or nothing

I don't take untyped work anymore. Not the frontend, not the backend, not the mobile app. If a project can't be TypeScript from the phone to the database, I'm probably not the right person for it.

That sounds rigid. It's the opposite. One language across the whole stack is the single biggest thing that lets a small team, or one person, move like a bigger one. I've watched it save clients weeks, and I've watched untyped codebases eat those same weeks alive at 2am.

One language, phone to database

Here's the shape of a project I'd take on:

• Web frontend in React with a full-stack framework, all TypeScript.
• Mobile in Expo and React Native, same language, often sharing code with the web.
• Backend in Hono or a framework route handler, TypeScript again.
• Database through Drizzle, where the schema is a type.

Four surfaces, one language. A developer who fixes a bug on the web can fix the same class of bug on mobile without a context switch. That's not a small convenience. That's the difference between one person covering the whole stack and needing three.

Types that cross the wire

The real payoff shows up at the seams. When your API and your client share types, a change to the backend shows up as a red squiggle in the frontend before you ever run it.

// shared package
export type Post = { id: string; title: string; publishedAt: Date }
 
// backend returns Post
// frontend consumes Post
// rename `title` to `heading` and both sides break in your editor, not in prod

Rename a field on the server and the client won't compile until you fix it. No stale DTO. No "works on my machine." The compiler is the integration test you didn't have to write.

Mobile isn't an exception

People treat mobile like a different country with its own rules. It isn't, not anymore. Expo lets me write a React Native app in the same TypeScript, share validation and types with the web through a shared package, and ship to iOS and Android from one codebase.

The client who wanted "an app version later" is delighted when later takes days instead of a rewrite, because the hard parts, the types and the logic, already exist. That only works if mobile speaks the same language as everything else.

The pushback, and my honest answer

I get the objections. Here are the real ones.

"TypeScript slows us down at the start."

It does, a little. You write types you didn't write before. Then it pays that back with interest the first time you refactor without fear, and every time after. Fast at the start and slow forever is a bad trade. I'll take the reverse.

"Our team only knows JavaScript."

TypeScript is JavaScript with a safety net. A JS developer is productive in it in a week and never wants to go back. I've onboarded people who grumbled on Monday and evangelised by Friday.

Where I'd actually loosen up

I'm a die-hard, not a zealot. A throwaway script, a one-off migration, a prototype you'll delete on Friday, sure, reach for plain JS and move on. The rule is for code that has to live, get maintained, and get handed to someone else. That's most of what anyone pays me to build.

And any exists for a reason. Used once, deliberately, at a genuine boundary, with a comment, it's a pressure valve. Sprayed across a codebase, it's a confession that the types were too hard and nobody wanted to fight them. I fight them.

Frequently asked questions

Isn't this just personal preference?

Partly, and I won't pretend otherwise. But the shared-types-across-the-wire argument is structural, not aesthetic. On any project with a client and a server, end-to-end types catch a category of bug that no amount of discipline catches by hand.

Does TypeScript help on small projects?

Most, actually. Small teams can't afford a QA department, so the compiler becomes one. The fewer people you have, the more you want the machine catching mistakes while you sleep.

What about React Native and Expo specifically?

Same story, same benefits. Expo's tooling is TypeScript-first, and sharing a types package between your web and mobile clients is where the one-language stack stops being a nice idea and starts saving real money.

Do you ever inherit JavaScript projects?

Yes, and I migrate them incrementally. TypeScript is designed for exactly that: rename a file to .ts, fix what lights up, repeat. You don't need a big-bang rewrite to start getting value.

The whole thing in one line

One language from the phone to the database means one person can own the whole stack, and the compiler catches the mistakes before your users do. That's not dogma. That's an edge you keep.

If you want the backend half of this, here's why my APIs start with Hono. If you're weighing the frontend half, I compared Next.js and TanStack Start. And if you've got something to build, tell me what it is.