Next.js & TypeScript product work
Application work in TypeScript and Next.js — greenfield App Router builds, rescue work on a codebase that has stopped being fun, typed API boundaries with tRPC or gRPC, installable PWAs, and Core Web Vitals that hold up.
TypeScript end to end, Next.js on the App Router, React Server Components where they pay for themselves and plain client components where they do not.
What this looks like
- Greenfield builds: a product from an empty repository to a deployed, monitored application.
- Rescue work: inheriting a codebase that has grown faster than its structure, and making it safe to change again.
- Typed API boundaries: tRPC when the client and server share a repository, gRPC when services have to talk across language boundaries, plain REST when that is what the consumer needs. The interesting decision is which one, and why.
- Progressive web apps: service workers, offline behaviour, installability and push — built so that the offline story is designed rather than accidental.
- Design implementation: Figma files turned into components that match the file, on Tailwind CSS and shadcn/ui, with the accessibility behaviour intact rather than approximated.
- Performance and Core Web Vitals: finding out which of the three seconds is actually yours, with the protocol-level detail to back it up — caching headers, compression, waterfalls, hydration cost.
- Type-level work: turning runtime surprises into compile-time errors, properly typed API boundaries, schema-derived types instead of hand-maintained ones.
Working style
Small, reviewable pull requests against your branch, in your repository, with your CI. The point is to leave behind a codebase your team can maintain — not one that depends on Nixperts.