React 16 through 19, class components through Server Components, Redux through Zustand through RSC server state. 17 years. Fixed monthly price.
- Scope
- Ship
- Iterate
monthly subscription
Who this is for
You run a React SPA or a React-on-Next app and need someone who can own the architecture, not just close tickets. Maybe your component tree has grown into something nobody wants to touch. Maybe state management is a different answer in every file. Maybe performance is slipping and the team keeps saying it's on the roadmap. That is where I come in.
The pain today
- Component sprawl — nobody knows where the shared pieces live or why there are four versions of the same button.
- State management is whoever's religious preference got there first: useState trees, half-abandoned Redux, context doing things context was never designed for.
- Performance is dying in production: re-renders nobody profiled, bundle size nobody budgeted, waterfall fetches nobody drew on a whiteboard.
- Accessibility is the ticket that survives every sprint planning meeting and ships last, if at all.
- React 19 and Server Components look interesting but nobody on the team has time to evaluate them seriously.
The outcome you get
- A React engineer with production work across five different products, React 16 through 19.
- A state-management decision written down and applied consistently across the entire codebase.
- A performance budget measured, documented, and enforced in CI — not just promised.
- Accessibility baked into the component primitives, not bolted on at launch.
- A clear recommendation on React 19 and Server Components: adopt, wait, or skip for your specific stack.
React in production across five case studies
React is the one constant in my customer work. GigEasy was a fintech MVP — Laravel backend, React frontend, shipped to investor demo in 3 weeks against a typical 10-week cycle. bolttech was React plus NestJS at $1B+ unicorn scale, payment orchestration across 40+ providers with 99.9% uptime. Imohub was Next.js plus React plus Laravel, 120k+ real estate listings with sub-500ms query response. LAK Embalagens was React plus Next.js for a B2B manufacturer, 45% bounce rate reduction and a top-3 Google ranking. Instill is React 19 plus Next.js plus PostgreSQL, a self-initiated AI platform I built and run.
That is React 16 through 19, class components through function components through Server Components, Redux through Zustand through React Query through server state in RSC. Each of those products had a different team size, a different deployment environment, and a different set of constraints. The React stayed; the surrounding decisions changed.
A React engineer with production work across five different products, React 16 through 19.
What I actually look at when I join a React codebase
The first thing I read is not the code — it is the package.json and the state-management imports. They tell me almost everything about how decisions got made and who made them. Then I look at the component tree for colocation patterns: are hooks next to the components that use them, or scattered across a shared folder that became a junk drawer? Then I look at the data layer: is server state managed by React Query or are people fetching inside useEffect and storing results in useState?
From that audit I write a short document — usually one page — that names the three highest-leverage changes. I share it on day one. The team pushes back, we adjust, and that document becomes the north star for the engagement. Nothing gets shipped that contradicts it without a written reason.
40+: Payment providers integrated.
State, data, and structure — my defaults
Server state belongs in React Query or in RSC, not in Redux. Form state belongs in React Hook Form, not in local useState trees. Global UI state — theme, modals, auth — belongs in a small Zustand store or context, not in a 2,000-line Redux saga file.
Component structure follows colocation: the smallest useful unit lives next to its hook and its test. Storybook is optional; design-system components get it, feature components skip it. Every structural decision goes into the project README so the next engineer does not re-litigate it at 2am before a deploy.
On React 19 specifically: I recommend it for new projects starting on Next.js 15 or later. For existing React 18 apps, the migration is low-risk if the codebase is already hook-based and avoids legacy patterns. I have done that migration on production codebases.
Performance and accessibility baselines
Every React project I take on gets a performance budget before any code is written: First Contentful Paint under 1.8s on throttled 4G, Largest Contentful Paint under 2.5s, Total Blocking Time under 200ms, critical-path bundle under 200kb. Enforcement runs in CI via Lighthouse. If the app does not hit the budget on merge, the merge waits.
Accessibility follows the same baseline logic: semantic HTML first, keyboard navigation tested manually, ARIA only when the semantic element is genuinely insufficient, color contrast at WCAG AA minimum, automated checks via axe-core in CI plus a manual screen-reader pass on the three or four critical user flows. The baseline is not a checklist you run once before launch. It is a gate that runs every deploy.
How the engagement works
Applications subscription at $4,999 per month flat. Delivery cycles run two to four days — you see working software, not status updates about working software. Daily async updates in Linear or Jira. Weekly 30-minute call, no more unless you want more.
I work inside existing teams — pairing, code review, architecture decisions, handoff — or solo on a greenfield build. Either way, work is Made for Hire: every line of code is yours. 14-day money-back inside the first two weeks, no questions. After that, cancel anytime month to month. I take one to two new customers per quarter, so availability is real but not infinite.
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.
React 16 through 19. Current work is React 19 with Next.js 15 and React 18 with Vite, depending on the project. I have run migrations from 16 to 18 and 18 to 19 on live codebases, including one that had a mix of class components and hooks that needed untangling before the upgrade could happen.
Zustand for small global UI state. React Query for all server state. Jotai when atomic state makes sense for the data shape. Redux only on codebases that already have it — I do not introduce Redux to greenfield projects. The goal is the simplest state solution that does not require a PhD to debug at 11pm.
For new Next.js 15 projects, yes. RSC moves data fetching to the server, cuts client bundle size, and removes a whole class of useEffect fetching bugs. For existing apps, the answer depends on how much of the component tree is currently client-only. I assess that and give a written recommendation before any migration starts.
Yes. shadcn/ui is a common starting point for new projects; Radix UI plus Tailwind plus custom tokens is the standard pattern underneath it. I can adopt an existing design system rather than replace it — at bolttech I worked within an established system and extended it rather than rebuilding from scratch.
Yes. I have joined existing engineering teams at bolttech, Cuez, and GigEasy. I adapt to the branch conventions, PR templates, and CI setup already in place. The first week is mostly listening and reading code before proposing anything.
No. React Native is out of scope. My work is React for the web — SPAs, Next.js apps, and server-rendered React. If you need mobile, I can refer you to specialists I trust, but I will not take work I cannot do well.
Vitest or Jest for unit tests on logic and hooks. React Testing Library for component integration tests, focusing on user behavior rather than implementation details. Playwright for critical end-to-end flows. I do not require 100% coverage — I require that the paths where money moves have tests.