Hire React Developers: What It Costs and How to Vet Them

The job is architecture, not components

A React developer's real work is not building components. It is deciding where state lives, where the network boundary sits, and what re-renders when a user types. Nearly everything expensive in a React codebase traces back to those three calls, and they get made in the first two weeks by whoever you hired.

We took over a B2B dashboard last year that shows what that means in practice. Forty screens, eight months of work by a perfectly capable freelancer, and filtering the main table took close to a second per keystroke on a fast laptop. Nothing was broken, so nobody had flagged it. The React DevTools Profiler told the whole story in one flamegraph: filter state sat in a top level context, the provider passed a fresh object literal as its value on every render, and every consumer in the tree re-rendered on every character typed, including three charts that had nothing to do with filtering. That fix took an afternoon. The problem was that the same instinct was everywhere else: fifty useEffect calls fetching data behind hand rolled loading booleans, no AbortController, no cache, and two race conditions that flashed stale rows when a user clicked quickly.

None of that shows up in a demo. It shows up in month four, when adding a feature breaks something two screens away and velocity quietly halves. Buyers judge React developers on what they can build in a week, then live for years with what those developers architected during that same week.

Engagement models and what each one is good for

In-house hire. Right when React is your product surface for the long run, you have a design system or are about to build one, and someone senior can review pull requests. Wrong when you need output in six weeks. Recruiting a good React engineer takes real calendar time, and ramp on a non trivial codebase runs weeks. You are buying a decade of context, not a sprint.

Freelancer. Right for bounded work with a finish line: rebuild a checkout flow, migrate off Create React App to Vite, ship a marketing site in Next.js. Wrong as the sole architect of a long lived application. Freelancers optimise for visible progress because visible progress gets renewed, which is exactly how the dashboard above happened. Availability is unstable too. Good React freelancers get pulled onto better paying work, and mid migration is a bad time to lose your only person.

Agency. Right when you want the whole outcome owned, including design handoff, code review, QA and deployment, and you do not want to manage individuals. You pay a premium for that. The trade you are making is that agencies vary wildly in whether the senior who scoped your project is the one writing your code. Ask directly who is on the keyboard, and insist on meeting them.

Staff augmentation. Right when you already have an engineering lead and a backlog and need capacity that plugs into your GitHub org, your standups and your review process. Wrong if nobody is setting direction, because augmented engineers do what the ticket says and no more. Most of our React clients land here after trying the other three.

What it costs

Rates move with region and seniority more than with anything else. These bands come from Digital Heroes delivery and from what clients tell us they were quoted before they called us.

• Offshore and nearshore, mid to senior: roughly $25 to $75 per hour. This is the band we work in, with engineers who own architecture sitting at the top of it.
• Freelancers in the US, UK or Western Europe: roughly $60 to $150 per hour. The people who can debug hydration and read a render tree sit at the upper end and rarely negotiate.
• US or UK agency: roughly $120 to $250 per hour blended, which buys project management, QA and accountability alongside the code.

The in-house number people quote themselves is base salary, and base salary is the smallest part of it. Benefits, payroll taxes, equipment and software seats push the real cost meaningfully above base. An external recruiter adds a placement fee tied to first year salary. Then there is ramp: a competent React engineer joining a codebase of forty screens is not net productive for the first month or two, and that month bills at full rate whether or not anything ships. Every time we walk a client through this arithmetic, the first year commitment lands a long way north of the salary line they had in their head. That gap is why a lot of teams start with a pod and convert to in-house once the architecture is settled.

How to vet a React developer

Skip the trivia. Nobody needs to recite the reconciliation algorithm. Go at the three decisions that matter.

Server state versus client state. Ask how they handle data that lives on the server. A weak answer is useEffect plus useState plus a loading boolean. A strong one names TanStack Query, RTK Query or React Server Components and explains why: caching, deduplication, cancellation and invalidation are solved problems, and hand rolling them across thirty components is how race conditions get in. Follow up with what belongs in global client state. The good ones say very little, usually auth, theme and a couple of UI toggles, and they reach for Zustand or Jotai before putting the world in Redux or a context tree.

Effects. Ask when useEffect is the wrong tool. You want to hear that effects synchronise with external systems, and that deriving state from props, fetching server data, and chaining effects that set state which triggers another effect are all smells. Someone who cannot articulate that will write the dashboard from the opening of this page.

Performance. Ask for one performance bug they fixed and make them narrate the Profiler flamegraph. Real answers are boring and detailed: a component re-rendering on an inline object prop, a list keyed by index so React rebuilt every row on reorder, a heavy chart sitting unmemoised inside a context consumer. If everything in their code is already wrapped in useMemo and useCallback, that is not performance work.

Next.js, if you are on it. Ask what breaks when you put 'use client' at the top of your root layout, and how they debug a hydration mismatch. Half the people who list App Router experience cannot answer either. Good answers cover pushing the client boundary down the tree, keeping data access on the server, and the classic mismatch causes: dates rendered with toLocaleString, Math.random, and reading localStorage during render.

The take-home. Three to four hours, paid, and shaped like real work: a filterable, paginated table hitting a real API, plus one form. Then read it for the things that separate seniors from mid levels. Are filters synced to the URL so a view is shareable and the back button works? Is the search input debounced? Are in flight requests cancelled or otherwise race safe? Is the empty state visually distinct from the error state, or are they the same grey box? Is the form using React Hook Form with a Zod schema, or forty lines of manual onChange handlers? Are the API types real, or is any smeared across the boundary? Is there one test that means something, using React Testing Library and querying by role rather than by test id?

Portfolio review. Do not read a PDF. Open the deployed app. Throttle the network in DevTools and watch what happens. Check the Network tab for a three megabyte JavaScript bundle on first load. Open the Profiler and type into a filter. Tab through a modal and see whether focus is trapped and whether Escape closes it. Resize to 375 pixels. Five minutes of that beats an hour of conversation.

Red flags

• useMemo and useCallback on everything, with no measurement. Ask to see the before and after Profiler flamegraph for one of them. Silence means they memoise out of superstition and have never profiled anything.
• Data fetching in useEffect across the whole app. Ask how they cancel a request when the component unmounts mid flight, and how they invalidate after a mutation. If the answer is a boolean called ignore, they are hand building a cache library badly.
• A portfolio of landing pages and clones. Beautiful Tailwind marketing sites prove nothing about a stateful application. Ask to see something with authentication, role based access and more than twenty screens, then ask what they would do differently now.
• "Senior, five years of Next.js App Router." The App Router has not existed that long. Ask what they migrated from and what broke during the migration. Vague answers here predict vague code.
• Redux Toolkit wired into everything, or one giant context provider. Ask which of that state genuinely needs to be global. If the answer is most of it, they have not thought about it once.

When to hire someone else instead, and how we staff it

Do not hire a React developer if your actual problem is a four second API response. No amount of Suspense makes a slow backend fast, and you will pay a frontend specialist to build increasingly clever loading skeletons over a problem that lives in your database. If you need one person to ship a whole product, hire a full stack TypeScript engineer, because you need someone who can move an endpoint as easily as a component. If your product is a mobile app, that is React Native, which is a different job involving native modules, EAS builds and platform specific bugs. And if you mostly need pixel accurate marketing pages, a design engineer will serve you better than an application developer.

A React specialist pays for themselves when you have a real application, a growing screen count, and a team that needs patterns it can follow. Digital Heroes staffs that as a pod: one senior React engineer owning state architecture, the data layer and code review, plus one or two mid level engineers on feature work, running inside your GitHub organisation on your branch and review rules. We start with a small paid slice, usually two weeks against a defined outcome, so you can read our pull requests before committing to anything longer. The code is yours from the first commit, in your repo, under your licence.