TypeScript across Node backend and React frontend. Shared types via Turborepo monorepo. Shipped at bolttech ($1B+ unicorn) and Instill (AI startup). $4,999/mo flat.
- Scope
- Ship
- Iterate
monthly subscription
Who this is for
You're a seed or Series A startup that has committed to a Node plus React plus TypeScript stack and needs a senior engineer who has actually run it in production — not someone who will figure it out on your dime. You may have a working prototype, an overwhelmed founding engineer, or nothing yet. What you don't have is the architecture discipline: the monorepo structure, the shared type layer, the queue setup, the deploy story, the test coverage. That's where I come in.
The pain today
- Types defined twice — once in the backend, once in the frontend — and they drift apart within a week.
- Next.js route handlers are doing the work of a real backend service, and the codebase is starting to feel it.
- The team debated NestJS for six weeks and still hasn't started the actual feature.
- No queue, no retry, no dead-letter — background jobs are just setTimeout calls in a Vercel function.
- Every deploy is manual, every secret is in Slack, and nobody owns the CI config.
The outcome you get
- A Turborepo monorepo with shared Zod schemas and TypeScript types that both ends import — types defined once, never drifting.
- A clear verdict on NestJS vs Fastify vs Next.js route handlers for your specific scope, written in the first week.
- BullMQ queues on Redis for background jobs — with retry logic, dead-letter queues, and observability from day one.
- GitHub Actions CI/CD, Vitest unit tests, Playwright E2E — the full discipline, not just the happy path.
- A senior engineer who shipped this exact stack at a $1B+ unicorn and an AI startup, available on a flat monthly subscription.
The reference architecture I actually deploy
My default Turborepo monorepo layout has three top-level workspaces: apps/web (Next.js with React Server Components or Vite plus React, depending on backend coupling), apps/api (NestJS or Fastify, depending on domain complexity), and packages/shared (Zod schemas, TypeScript interfaces, domain models — imported by both sides). Node 20, TypeScript strict mode everywhere. Prisma plus PostgreSQL for relational SaaS; Mongoose plus MongoDB when data is genuinely document-shaped with variable fields. BullMQ on Redis for background jobs. Auth via Clerk for speed or Auth.js for control. Vitest for unit and integration tests, Playwright for end-to-end. Deploy: Vercel for the web app, Fly.io or AWS ECS Fargate for the API.
For the ORM choice in 2026: Prisma is still the safer default for complex migrations and team readability. Drizzle is the right pick when raw SQL performance matters or bundle size is a constraint. I've shipped both; I pick based on the data model, not preference. Turborepo over Nx for most startups — simpler mental model, faster cache, Vercel-native integration. Nx makes sense when the team already has Nx expertise or needs Nx-specific plugins.
A Turborepo monorepo with shared Zod schemas and TypeScript types that both ends import — types defined once, never drifting.
When to use NestJS, Fastify, or Next.js route handlers
This is the decision that stalls more TypeScript startups than any other. My framework for it is simple.
Next.js route handlers: use when the backend is light (under 15 endpoints), lives alongside the UI, and shares types so tightly that a separate service would just add network overhead. Most early-stage products start here.
Fastify (or Hono for edge): use when you need a lean, fast HTTP layer with clear service boundaries and under 30 endpoints total. Fastify's TypeScript support is first-class, and Hono adds genuinely useful edge runtime support if you're deploying to Cloudflare Workers.
NestJS: use when the domain has real structure — multi-tenant B2B SaaS, fintech, complex permission layers, or a team of three or more engineers who need convention over configuration. bolttech ran NestJS plus React plus MongoDB plus Redis at $1B+ unicorn scale: 40+ payment providers, 15+ international markets, 99.9% uptime, zero post-launch critical bugs. That's the ceiling this stack can reach.
The mistake I see most often: teams commit to NestJS in week one because it sounds professional, then spend two months fighting its module system before shipping a single user-facing feature. The right answer is written in a discovery session, not decided by whoever opens the first PR.
40+: Payment providers integrated.
Shared types: the one architectural decision that pays back forever
The biggest Node plus React productivity multiplier is not the framework — it's the shared type layer. When your Zod schema lives in packages/shared and both the NestJS DTO and the React form import from it, you get three things for free: a type error when you rename a field (instead of a runtime crash), auto-generated API docs via OpenAPI, and a contract that forces backend and frontend to agree before either starts coding.
I set this up on day one of every engagement. The Turborepo cache means the shared package only rebuilds when it changes. TypeScript project references keep the incremental build fast even as the monorepo grows. The end result: I spent a week at Instill wiring this up before writing a single feature, and the entire product shipped without a single frontend-to-backend type mismatch in production. 1,000+ skills, 45+ projects, 30+ active users — all running on that shared contract.
Queues, auth, and the infra you skip at your own risk
Three infrastructure pieces that most TypeScript startups defer until they hurt.
Queues. If you have a webhook, a background email, a PDF generation job, or anything that should not block an HTTP response, you need a queue. BullMQ on Redis is my default: well-documented, excellent TypeScript types, built-in retry with exponential backoff, dead-letter queue, and a UI dashboard via Bull Board. A Vercel serverless function with a 10-second timeout is not a queue, even if it feels like one.
Auth. Clerk is the fastest path for most startups: React components out of the box, webhooks for user events, multi-tenant support, and solid TypeScript SDK. Auth.js (formerly NextAuth) when you need full control over the session store or have a compliance requirement that Clerk's cloud storage can't satisfy. Custom Passport plus JWT only for greenfield APIs where Clerk's pricing at scale is a concern and the team can own the implementation.
Observability. A structured logger (Pino) and a single trace ID per request. Takes half a day to set up, saves hours every time something breaks in production. I wire it up before the first feature, not after the first incident.
Deploy story: Vercel plus Fly.io is the default in 2026
For the web app, Vercel is the obvious choice when you're on Next.js: zero-config builds, RSC support, edge middleware, preview deployments per branch, and Turborepo remote caching built in.
For the API, the choice in 2026 is between Fly.io and AWS ECS Fargate. Fly.io wins for early-stage: $1–5/month for a persistent Node container with zero ops overhead, global anycast routing, and a ten-minute deploy setup. ECS Fargate is the right move once you need VPC peering, fine-grained IAM, or you're already on AWS for other services.
GitHub Actions handles CI: lint, type-check, unit tests, build — all in parallel via Turborepo's remote cache. A failed type-check blocks the deploy. A passing Playwright run on the preview URL gates the merge to main. This is the discipline that keeps a TypeScript codebase from turning into a JavaScript codebase that happens to have .ts file extensions.
What the subscription covers
Applications subscription at $4,999 per month flat. Two to four day delivery cycles. Daily async updates. 14-day money-back guarantee. Cancel anytime after that.
Work Made for Hire on everything: monorepo structure, shared packages, deploy configs, CI/CD pipelines, API services, React components — all yours from day one. I take on one customer at a time by design, which means you're not sharing attention with a dozen other projects.
Discovery is the first two to four days. I map the existing codebase (or sketch one from scratch), write the framework decisions document, and set up the Turborepo workspace before any feature work starts. That document is yours regardless of what happens next.
Recent proof
A comparable engagement, delivered and documented.
Unified payment orchestration across Asia and Europe
Delivered the payment orchestration platform at bolttech, a $1B+ unicorn, with 40+ integrations across multiple regions.
Read the case studyFrequently asked questions
The questions prospects ask before they book.
Yes, with one refinement: replace 'JavaScript' with 'TypeScript' everywhere and 'Create React App' with Vite or Next.js. MongoDB, Express, React, and Node remain solid choices, but the stack I deploy is TypeScript-first, uses NestJS or Fastify instead of raw Express, and runs in a Turborepo monorepo with shared types. The core idea — one language on both ends — is still the right call for lean startup teams.
Put your Zod schemas and TypeScript interfaces in a packages/shared workspace inside a Turborepo monorepo. Both apps/api and apps/web add it as a local dependency. TypeScript project references keep incremental builds fast. The result: rename a field in the shared schema and both ends break at compile time, not in production. This is the single highest-leverage architectural decision for a Node plus React team.
Turborepo for most startups: simpler setup, faster task caching, and native Vercel integration. Nx is worth considering when the team already has Nx expertise, needs its code generation features, or is running a larger multi-team repository. For a team of one to four engineers shipping a Node plus React product, Turborepo's mental overhead is lower and the cache warm-up is noticeably quicker.
Prisma for most teams: mature migrations, excellent TypeScript inference, readable schema file, and wide ecosystem support. Drizzle when raw SQL performance matters (it generates closer-to-optimal queries) or you're optimizing bundle size on an edge runtime. Both work well in a Turborepo monorepo. The ORM choice is less important than the discipline around migrations — pick one and enforce it consistently.
When one of these is true: the backend logic is complex enough to need its own test suite, the API will be consumed by non-React customers (mobile apps, third-party integrations), or the team has grown past two engineers and needs clearer service boundaries. At bolttech, a dedicated NestJS service handled 40+ payment provider integrations at $1B+ unicorn scale. That level of complexity demands its own service. A three-endpoint MVP does not.
Discovery takes two to four days: I read the existing codebase or sketch the architecture from scratch, then write a decisions document covering framework choices, monorepo layout, database, auth, and deploy story. Feature work starts after that. Delivery cycles run two to four days. Daily async updates, never silence. 14-day money-back guarantee if it's not working in the first two weeks.