Why we standardize on TypeScript across every project

Every Stacklane codebase is TypeScript end to end: backend, frontend, mobile, scripts, infra-as-code. The decision is not a religious one. The reason we hold the line is operational: with two senior engineers rotating across client codebases on a subscription model, the cost of context-switching is the thing we have to keep low. TypeScript is the largest single lever we have on that cost.

The actual benefit is the refactor

Type checking catches bugs, sure. The bigger payoff is mechanical refactoring: rename a field, change a function signature, restructure a domain model, and the compiler walks you through every site that needs to change. On a JavaScript codebase the same refactor is a grep-and-pray exercise. The first time you save eight hours on a model migration because the compiler told you exactly where to look, the runtime tax of `tsc --noEmit` pays for itself.

Refactor-without-fear is also what lets us pause an engagement and resume three months later without spin-up cost. The codebase tells the returning engineer what changed and what broke. That is impossible on JavaScript past a certain codebase size.

Where we keep the type system on a leash

• No conditional-type gymnastics in application code. If a type takes longer to write than the function under it, the function is wrong, not the type.
• `zod` (or `valibot` for smaller bundles) for runtime validation at every boundary the compiler can't see: API requests, env vars, third-party webhook payloads. Schemas double as the source of truth; types are derived from them.
• `as` casts are a code smell, not a tool. We allow them at one place only: parsing fully validated external data into a typed shape, after the schema check has already passed.
• We never use `any`. `unknown` is fine. `never` shows up only inside discriminated-union exhaustiveness checks.

Where TypeScript is not enough

Types do not catch logic errors, performance regressions, or n+1 queries. They do not check that your migration is reversible or that your background job is idempotent. We rely on a small suite of integration tests, a structured code-review checklist, and an unsexy operational habit of running everything in production against a real dataset before declaring it done. TypeScript is a force multiplier on top of those, not a replacement for them.