TypeScript is my main language, and over the years it stopped being just a language choice and became a set of values. Not rules from a style guide - habits that decide whether a codebase is still pleasant to change after two years and three new developers.
Honesty over convenience. Strict mode is on from the first commit. any is a bug report, not a type; when I truly do not know the shape, it is unknown, and I narrow it. A type that lies - an as cast to silence the compiler - is worse than no type, because everyone downstream trusts it. When the compiler complains, it is usually right, and the fix is in the data, not in the annotation.
Make impossible states impossible. Instead of isLoading, isError, and data as three flags that can contradict each other, a discriminated union: idle, loading, success with data, error with a reason. The same goes for domain states - a paid order has a paymentId, an unpaid one does not. A switch with an exhaustive never check turns “we forgot a case” from a production incident into a red line in the editor.
Trust inside, verify at the edges. Types vanish at runtime, so everything that crosses a boundary - an HTTP body, a webhook, a form, localStorage, an LLM response - is parsed with Zod or a similar schema, and the type is inferred from that schema. One source of truth, no drift between what we validate and what we believe. Inside the app, typed data flows without defensive checks on every line.
Share contracts, not guesses. In a full-stack product the API types are generated or shared - from OpenAPI, GraphQL codegen, Prisma, or a shared package - so a renamed field breaks the build, not the checkout. And readability beats cleverness: a plain interface a new hire understands in ten seconds is worth more than a five-level conditional type that proves I read the handbook. Generics are for reuse, not for showing off.
Types do not replace tests, reviews, or thinking - they make all three cheaper. That is the real value of a TypeScript developer: not knowing every utility type, but leaving behind code the next person can change with confidence. If your codebase is full of any and the team is afraid to refactor, send me the module nobody wants to touch. I will reply with how I would type it and what that would catch.
Give the next product someone who stays.
Ready to get started? Send me a message - I'm available to start now and to stay. Long-term retainers, not a two-week handoff. Let's discuss your project, requirements, and the best way to move forward.