Technologies / TypeScript
We default to TypeScript across the front end, the back end, and the shared contracts between them. It removes a category of bugs before they ship.
TypeScript is the single technology choice that has changed how we deliver more than any other. Shared types between the API and the UI, refactors the compiler can catch, and codebases that scale to real team sizes without collapsing. We use TypeScript across React, Node, and the shared packages that bind them together.
We use TypeScript where it earns its place. These are the situations we see most often.
A field renames, and neither side notices until QA — or, worse, until production.
In a large JavaScript codebase, changing a signature is an act of faith. Grep and pray.
A tsconfig with strict off, `any` everywhere, and no real type safety — the worst of both worlds.
We start with your business problem — the process, the users, the constraints — before naming any technology, including this one.
A clear architecture decision record: where this technology fits, where it doesn't, and what it integrates with.
Small, demonstrable increments on real data. Real users, real feedback, real outcomes — not a proof of concept nobody uses.
Operational metrics, documentation, and a runbook your internal team can operate. We're not a lock-in vendor.
One source of truth for API shapes, shared between front and back end.
Refactors the compiler can verify — enabling large, confident changes to move quickly.
Strict TypeScript with `any` treated as a code smell, not a fallback.
Team ramp-up measured in days because the types describe the system.
React on the front end, Node on the back end, and shared type packages between them.
Turborepo or Nx to organise multi-package estates, with a build cache that keeps CI fast.
tRPC or codegen from OpenAPI/GraphQL so the client always knows the shape of the server.
Incremental adoption in an existing JS codebase, module by module, without a big-bang rewrite.
Getting from 'TypeScript on' to genuinely strict TypeScript deliberately, without paralysing delivery.
Types as a design tool — expressing domain concepts, not just placating the compiler.
A B2B operator had four repositories drifting apart, sharing code by copy-paste. We consolidated to a Turborepo monorepo with shared types, shared UI, and a shared API client — cutting release effort and eliminating a class of integration bugs.
A React estate had TypeScript on but strict off and `any` widespread. We ran a strictness migration in phases, ending with strict everywhere and a codebase that new hires could safely refactor from week one.
Vignettes are anonymised composites drawn from engagements and product work. No client names, logos, or performance figures are implied.
Usually yes, once the project outgrows a single file. The tooling ceremony has become minimal.
tRPC when the UI and API are the same team's TypeScript codebase; GraphQL where multiple consumers or federation matter.
Rename to .ts, allow implicit any, tighten module by module. Never a big-bang rewrite.
Only when they earn their place. Readable types beat clever ones.
We use both in specific contexts (Supabase Edge, scripting, benchmarks). Node remains the default runtime for most work.
TypeScript isn't a project — it's a discipline. If you're wondering how much of your stack should be typed, let's have that conversation.
Book Your Free Discovery Call