TypeScript · Strict mode · Codegen · Training

TypeScript Consulting Services

TypeScript pays for itself when the type system catches the bugs before the test suite does. Most codebases never get there. Too many anys, no codegen at the API edge, advanced type features used only by accident. I help teams build the type architecture that actually pulls its weight.

When teams call me for TypeScript

  • Migrating to strict mode

    noImplicitAny, strictNullChecks, strictFunctionTypes, one flag at a time, with a migration plan that lets the team keep shipping. Without a plan this work stalls indefinitely.

  • Types drift at the API edge

    Backend ships a change, frontend types are stale, runtime errors in production. I set up GraphQL or OpenAPI codegen so the types are generated from the source of truth and can't drift.

  • Generic helpers are out of reach

    The team writes good application code but reaches for any the moment a utility needs to be generic. I write the utilities, document the patterns, and train the team to maintain them.

  • Component prop APIs are sloppy

    Boolean props proliferating, illegal combinations representable in the type, runtime checks where the type system should be enforcing. I rebuild prop APIs with discriminated unions so wrong usage doesn't type-check.

Where I go deep

Mapped & conditional types

Building type-level utilities that transform other types. Partial-style helpers, recursive structures, key remapping, infer in conditional types.

Discriminated unions

Designing prop APIs and state machines where illegal states are unrepresentable. Tagged unions over loose object types.

Codegen pipelines

GraphQL Code Generator with Apollo or urql, OpenAPI to typed fetch clients, Zod-based runtime validators that share types with TypeScript.

Strict-mode rollouts

Incremental migrations on legacy codebases. Module boundaries, // @ts-expect-error as a transition tool, build gating to prevent regressions.

Inference design

Writing functions and components whose return types are inferred from usage rather than annotated. The difference between a library that's pleasant to use and one that isn't.

React + TypeScript patterns

Polymorphic components, generic hooks, context with literal types, ref forwarding without losing types, Server Components and async types.

Things I've written on this

Public proof beats slide decks. The posts below are how I think about TypeScript, and the level of detail you can expect in an engagement.

How I engage

TypeScript review

1–2 weeks. Codebase walkthrough, written assessment, prioritized plan. Best entry point if you're not sure where the work is.

Migration project

4–12 weeks. Strict-mode rollout, codegen pipeline, or type architecture rewrite. Embedded with the team, shipping with them.

Team training

Workshops on advanced types tailored to your codebase. Written materials, live sessions, follow-up pairing.

Frequently asked

Can you migrate our codebase to TypeScript strict mode?
Yes. Strict-mode rollouts are one of the most common engagements. The work is incremental (one flag at a time, one module at a time) with a written plan so the team can keep shipping features during the migration.
Do you work with GraphQL and REST codegen?
Both. GraphQL Code Generator (Apollo, urql, raw fetch) and OpenAPI/Swagger codegen for REST. The goal is the same: types at the API boundary that can't drift from the source of truth.
Will you train the team or just write the code?
Either. Most engagements include written explainers and pairing sessions on the advanced patterns used in the work (mapped types, discriminated unions, conditional types, generics) so the team can maintain what I ship without me.
How is this different from just hiring a senior engineer?
Most senior engineers know enough TypeScript to ship. Few are comfortable in the type-level half of the language (mapped types, conditional types, template literal types, custom type-level utilities). That's the work this engagement is for.