Hire Frontend Developers: What They Cost and How to Vet Them

What a frontend developer actually does, and where hiring goes wrong

A frontend developer owns everything the user touches: the component tree, the state that flows through it, the network layer that feeds it, the accessibility semantics, and the performance budget that decides whether your page paints in 900ms or four seconds on a mid-range Android phone in a parking lot.

A client came to us with a React dashboard built by a contractor who had shipped a genuinely beautiful Figma-to-pixel translation. Every screen matched the mock. Then the data grew. The main table re-rendered every row on every keystroke in the filter box because the filter state lived in a top level context provider that wrapped the entire app. Typing "acme" froze the tab for six seconds. The contractor's fix had been to add a debounce, which just moved the freeze later. Nobody had ever opened React DevTools Profiler. Nobody had ever run Lighthouse on the actual page with real data. The build shipped a 3.2MB main bundle because moment.js with all locales, the full lodash package, and three icon libraries had been imported at the root.

That developer was not lazy. He was a designer who learned React. He could build a component. He could not reason about when a component renders, why, or what it costs. A portfolio of pretty screenshots will never reveal that gap.

The other failure mode is the opposite: an engineer who writes immaculate TypeScript generics, argues about whether the state should live in Zustand or Redux Toolkit for three days, and cannot make a modal close on Escape or trap focus inside it. Both are expensive. Both look great in a 30 minute chat.

Engagement models and the trade-offs

In-house full-time hire. Right when frontend is your product surface and you will keep changing it for years: a SaaS app, a marketplace, anything with a design system that needs an owner. The person accumulates context you cannot buy back later, which is the real asset. The cost is speed. A serious frontend search in a competitive market runs six to twelve weeks of sourcing and interviewing, then another four to eight weeks before they are shipping without hand-holding. You are also committing before you know if the workload is permanent.

Freelancer. Right for a bounded piece of work with a clear finish line: a marketing site, a Next.js migration off a legacy Create React App setup, a component library extraction. Cheap and fast to start. The risks are real: no bus factor, availability that evaporates when a better contract appears, and code that follows their preferences rather than your conventions unless you write those conventions down first. Never hand a freelancer your core product architecture.

Agency. Right when you need a whole outcome and do not want to manage the how: design, frontend, backend, QA, deploy. You buy a process and a delivery guarantee. You pay a premium for the layer of management and you get less say over which individual sits on your project. Watch for the classic bait and switch where the senior who sold you the project vanishes after week two.

Staff augmentation. Right when you have an engineering team and a queue that is longer than your headcount. You get a named developer who works inside your repo, your standups, your PR review, but you skip the recruiting cycle and the payroll commitment. This is how most of our frontend engagements at Digital Heroes run. The trade-off is that it only works if you have someone senior enough to review the work. Staff augmentation with nobody watching is just an expensive freelancer.

What it costs

These are ranges from our own delivery and from what we see in the market when we compete for the same work. They are not from a salary study, and anyone quoting you a precise market average for "frontend developer" is selling something. Rates swing hard on region, seniority, and whether the person has owned a production app or just contributed to one.

• South Asia and Southeast Asia: roughly $25 to $60 per hour. The top of that band buys real quality. The bottom buys someone who will translate a Figma file and not much more.
• Eastern Europe and Latin America: roughly $50 to $110 per hour for mid to senior. Strong pool, and timezone overlap with the US East Coast in the LatAm case.
• US, UK, Western Europe: roughly $90 to $175 per hour contract, higher for a specialist who does performance or accessibility work exclusively.

For an in-house hire, the salary number is the smallest part of the story. In our own hiring, payroll taxes, health insurance, equipment, software seats and general overhead add roughly a quarter to a half again on top of base, more in countries with heavier employer contributions. Then add recruiting: either an agency fee that is a real percentage of first-year salary, or your own engineers spending dozens of hours in interviews, which is not free either. Then add ramp. A frontend developer joining a codebase of any size is not net-positive in month one. They are reading, asking, and occasionally breaking things. Budget two to three months before you are getting full value.

Run the comparison properly. By the time we have helped clients work this out, a $120,000 base frontend hire routinely lands north of $170,000 in year one once everything is counted, and you are locked in. A staff-augmented senior at $70 per hour for six months costs less than that and stops when you say stop. The in-house hire wins on year three. It rarely wins on year one.

How to vet a frontend developer

Skip the algorithm puzzles. Nobody inverts a binary tree in a React component. Here is what separates people.

Rendering and state. Ask: "A parent component re-renders. Which children re-render, and what would you do to stop it?" A good answer covers React's default behavior, where memo helps and where it does not, why useCallback without memo on the child is theater, and why moving state down or lifting content up as children often beats memoization entirely. Then ask them to walk you through a time they opened the React Profiler. If they have never opened it, they have never debugged a real performance problem.

Data fetching. Ask what happens when two components request the same data at the same time. Someone who has shipped will immediately talk about TanStack Query or SWR, cache keys, stale-while-revalidate, and request deduplication. Someone who has not will describe a useEffect with a fetch inside it and no cleanup, which is a race condition waiting to happen. Follow up: "What breaks if the component unmounts before the fetch resolves?"

Next.js and server components. If your app is on the App Router, ask where the boundary between server and client components sits, and what happens when they add use client to a component that imports half the app. Ask what causes a hydration mismatch and how they debug one. Ask what belongs in a route handler versus a server action, and where they would put a secret. Someone who has only worked in the Pages Router or in plain Vite will say so, which is fine, but you should know that before they start.

CSS and layout. Ask them to explain a stacking context, or why their z-index of 9999 did not work. Ask about the difference between a flex container's align-items and align-content. This sounds basic. Many React developers cannot answer it, and it is exactly why your modal renders behind the header.

Accessibility. Ask: "Build me a dropdown. How does a keyboard user close it?" You want to hear about focus management, Escape handling, aria-expanded, and returning focus to the trigger on close. Bonus if they say they would reach for Radix UI or React Aria rather than hand-roll it, because that answer means they know how much there is to get wrong.

TypeScript in practice. Ask what they do when an API returns a shape their types do not match. If the answer is "cast it with as," that is a person who uses TypeScript as decoration. Good answers involve validating at the boundary with something like Zod and letting types be inferred from there.

The take-home. Do not ask for a to-do app. Give them a real, small, ugly problem: here is a JSON endpoint with 5,000 records, build a searchable, sortable, paginated table that stays responsive while typing, works with a keyboard, and does not fetch on every keystroke. Give it a four-hour cap and say you mean it. Then review the diff, not the demo. Look at whether the filter state is derived or duplicated, whether the list is virtualized or naively mapped, whether loading and error states exist, whether the table headers are actual th elements with scope, and whether the commits show a sequence of thought or one giant "done" blob.

The portfolio review. If they show live sites, open DevTools while they watch. Check the Network tab and the bundle size. Run Lighthouse. Tab through the page with the keyboard. Then ask, without judgment, "what would you fix here now?" The honest senior will have a list ready. The pretender will tell you it is perfect.

Red flags

They cannot describe a performance problem they personally fixed. Every frontend developer with real mileage has one story about a list that janked or a bundle that ballooned. Ask instead: "What is the slowest thing you have shipped, and what did you do about it?" Silence here is disqualifying for anything senior.

Everything lives in useEffect. If their code syncs state to other state through effects, derives values in effects, and fetches in effects with no abort handling, you are looking at someone who learned React through tutorials and never read the docs on when you do not need an effect. Ask: "When would you not use useEffect?"

They reach for a state library before they need one. A candidate who says "I always set up Redux first" has never lived with the consequences. Ask what they would use for server data versus UI state, and listen for the recognition that most of what people put in global stores is just cached server data that TanStack Query should own.

Divs with onClick everywhere. A quick scan of any code sample for clickable divs, missing labels on inputs, or images without alt tells you accessibility was never a consideration. Ask: "How do you test that this works with a screen reader?" You are not expecting them to be an expert. You are checking whether the thought has ever occurred to them.

The pixel-perfect specialist who cannot talk about data. They show gorgeous work, but every question about caching, optimistic updates, or error boundaries gets a vague answer. This person is a UI implementer, not a frontend engineer. Both roles exist. Only hire the first one if that is what you need, and pay accordingly.

When to hire a frontend developer at all, and how we staff it

Do not hire a frontend developer if what you actually need is a designer. If your problem is that your product looks amateurish and you already have engineers who can implement, the bottleneck is design, not React. Hiring a frontend developer to fix a design problem produces well-built ugliness.

Do not hire a frontend developer if the real gap is a full-stack engineer. Early-stage teams often need one person who can move from a Postgres migration to an API route to the UI without a handoff. A frontend specialist will sit blocked waiting for endpoints. Hire the specialist when the UI complexity itself is a full-time job: a data-dense dashboard, a real-time collaborative interface, a design system consumed by multiple product teams.

Do not hire a frontend developer for a marketing site. That is a Webflow or a Next.js static build a good agency ships in weeks, and you do not need a permanent engineer maintaining a page of copy.

At Digital Heroes we staff frontend the way we would want it staffed for ourselves. Every developer we place has shipped and maintained a production React or Next.js app, not just contributed to one, and we test that with the same table exercise described above before anyone reaches a client. Engagements start with a two-week paid trial so you are judging real PRs in your repo rather than a resume. We work inside your GitHub, your review process, and your standups, and you own every line of code from the first commit. If the fit is wrong, you tell us in week two and we swap or stop, no notice period, no severance conversation.