Hire GraphQL Developers: Rates, Vetting and Engagement Models

What a GraphQL developer actually does once the schema hits production

A marketplace client handed us an Android home feed sitting at nine seconds p95. The query was completely ordinary: feed(first: 20) { edges { node { title thumbnail seller { name rating } } } }. The trace told the story. That one request fired 61 SQL statements: one for the feed, twenty for sellers, twenty for rating aggregates, twenty for images. The previous developer had wired every resolver straight to Prisma, shipped it, watched latency climb, and concluded that GraphQL is slow. GraphQL was not slow. Nobody had put a DataLoader in the request context, so every field resolver went to the database on its own.

That is what you are hiring for. A GraphQL developer designs a schema that reads like your business rather than your database tables, then makes the resolvers behind it survive query shapes they did not choose. Your clients pick the shape. The server has to be fine with all of them, including the ones nobody predicted.

Hiring goes wrong because two very different people answer to the same title. One is a frontend engineer fluent in Apollo Client or urql: fragments, colocation, graphql-code-generator, the normalized cache. The other is a backend engineer who designs the schema, writes resolvers, batches with DataLoader, decides nullability, puts authorization at the field level, and defends the endpoint against a nested query bomb. Both write "GraphQL" on the CV. Hiring the first and expecting the second is the most expensive mistake in this stack, and you usually discover it in week eight, when the schema is a mirror of your Postgres tables, every field is nullable, and the mobile team has started sending five queries per screen to work around it.

Engagement models and the honest trade-offs

In-house hire. Right when the graph is permanent and several teams depend on it. At that point the schema is a product: versioning, deprecations, a registry, contracts with app versions you cannot force-update. Somebody has to own that for years. The catch is time and money. People who have run a graph through a breaking change are not sitting in the applicant pool, and you pay them in the quarters when the schema barely moves.

Freelancer. Good for bounded work: build the gateway, kill the N+1s, convert offset pagination to cursor connections, wire codegen and schema checks into CI. Cheap and fast to start. The specific risk here is that a freelancer who leaves after ten weeks takes the reasoning with them. Why is Order.lineItems non-null. Why does the seller subgraph own the rating field. Why does that mutation return a union instead of throwing. You inherit decisions without the arguments behind them.

Agency. Right when schema design, resolvers, client integration and deployment need to move together, or when you have nobody in-house able to judge the work. You pay a blended rate that covers people you do not manage directly. Worse than a freelancer for a two-day fix, better than anything else for a first federated graph, where getting subgraph boundaries wrong costs a rewrite.

Staff augmentation. One or two GraphQL engineers inside your repo, your sprints, your review process. Fits when you have engineers but nobody who has run a graph in production. It works when someone on your side can point them at the right problems and read their pull requests. It fails quietly when nobody reviews, and you end up with a graph that is technically correct and commercially wrong.

Rates and what it really costs

These bands come from our own delivery and from the offers our clients compete against, not from a survey. Rates move with region and seniority, and the same engineer costs different money in Austin than in Krakow.

• South and Southeast Asia, senior: roughly $25 to $60 per hour
• Eastern Europe and Latin America, senior: roughly $45 to $85 per hour
• US, UK and Western Europe, senior contractor: roughly $85 to $160 per hour, with the top of that band for federation and gateway specialists
• Agency pods, blended: roughly $40 to $95 per hour depending on the mix of design, backend and client work

Something specific to this stack is worth knowing before you negotiate. The market prices GraphQL as if it were a language skill. It mostly is not. The premium belongs to people who have owned a schema through at least one breaking change and one performance incident, and in our screening those are a minority of the candidates who list GraphQL on a profile. Paying the bottom of a band for the middle of the pack is how projects lose money here, because the bill arrives later as a rewrite.

If you hire in-house, salary is not the cost. Employer taxes, benefits, equipment, tooling and workspace push base up by roughly a quarter to a third in the budgets we build with clients, more in higher-cost jurisdictions, so treat the loaded number as your real comparison against a contract rate. Recruiters we have worked alongside quote 20 to 25 percent of first-year salary on a contingency basis. Then ramp: in our experience a strong GraphQL engineer needs four to eight weeks before they can make safe schema changes in a graph they did not design, and longer when the graph is federated and the subgraph ownership is undocumented. Budget the first quarter as cost, not output.

How to vet a GraphQL developer

Skip the "what is GraphQL" questions. Ask these, in this order, and listen for the specifics.

"Show me a resolver returning a list with a nested association. Where does batching happen?" You want DataLoader constructed per request and placed in context. A module-level loader is a data leak between users, and candidates who have not been burned by it will not mention request scope at all. If the answer to N+1 is "we put Redis in front of it", they have not understood the problem.

"How do you decide nullable versus non-null, and what happens when a non-null field resolver throws?" The answer you want includes null bubbling: the error propagates to the nearest nullable parent and can wipe out an entire response. Good practice is non-null for what genuinely cannot be absent, nullable at boundaries where a downstream service can fail. "Everything nullable to be safe" and "everything non-null because TypeScript is nicer" are both wrong, for different reasons.

"Offset or cursor pagination, and why?" Listen for the Relay connection spec, cursor stability when rows are inserted mid-scroll, and why totalCount is often the most expensive field on the page.

"A client sends a fifteen-level nested query. What happens?" You want depth limiting, cost analysis with per-field weights, persisted query allowlists in production, and rate limiting by query cost rather than request count. Tools like GraphQL Armor are a reasonable mention. Turning off introspection is hygiene, not a defense, and a candidate who offers it as the whole answer has not thought about it.

"Where does authorization live?" Resolver and field level, with the viewer in context. A check at the HTTP handler is not enough when the same field is reachable through three paths in the graph. Ask exactly that follow-up.

"You need to remove a field the iOS app still uses. Walk me through the month." Want: @deprecated with a reason, operation traffic from a registry such as Apollo GraphOS or from logs, schema checks in CI that fail on a breaking change, then waiting out the old client version. Anyone who says "we ship it and tell them" has never had a graph with real clients.

"Subscriptions: how would you run them, and would you?" Listen for whether they push back at all. A candidate who has operated subscriptions talks about sticky connections behind a load balancer, a Redis or Postgres pub/sub backplane across instances, what happens to state on deploy, and whether polling or server-sent events would do the job for less operational cost.

Apollo Client debug: "The mutation succeeds, the list does not update." Good candidates walk through it: does the mutation return the object with its id, is the type normalized, are keyFields or typePolicies set, would cache.modify or an update function fix it. refetchQueries everywhere is a fallback, not a strategy.

The take-home. Three hours, a small repo, paid. Seeded Postgres, a schema with Author, Post and Comment, one resolver with an obvious N+1, and offset pagination. Ask for three things: batch it, convert to cursor connections, add a complexity limit, plus one test that asserts the number of SQL statements. What you learn is not whether it works. It is whether the loader is per request, whether the test asserts query count rather than response shape, and whether they regenerated types after touching the schema.

The portfolio review. Ask for an SDL file they wrote and read it together on the call. Do type and field names read like the business or like table columns. Do mutations return payload types with typed errors instead of throwing strings. Are inputs typed or dumped into a JSON scalar. Are interfaces and unions used where the domain is genuinely polymorphic. Then ask why each odd field exists. The answer tells you whether they designed the schema or transcribed a database.

Red flags

• Every field is nullable, and half the payloads are a JSON scalar. This is a developer avoiding schema design. Ask instead: what is your nullability policy, and show me a field you made non-null on purpose.
• They reach for Apollo Federation on a three-service system. Federation buys you team autonomy and charges you in operational complexity, entity resolution and cross-subgraph N+1. Ask instead: when would you keep one schema, and what would have to be true before you split it.
• "Hasura or PostGraphile means we do not need backend work." Auto-generated graphs expose your database shape and push all security into row-level policies most teams never write correctly. Ask instead: show me how you would enforce row-level security and add a computed field that is not a column.
• Frontend-only experience presented as GraphQL expertise. Fluent Apollo Client usage is a real skill and is not schema ownership. Ask instead: show me a schema you designed and defend three of its decisions.
• They blame GraphQL for latency without a trace. Anyone who has operated a graph reaches for tracing first, per-resolver timings, then batching. Ask instead: walk me through the slowest query you ever fixed and what the trace showed before and after.

When to hire someone else instead, and how Digital Heroes staffs it

GraphQL earns its cost when several clients want different shapes of the same data: an iOS app, an Android app, a web app, maybe partner integrations, or when you are stitching together services that were never designed to be one API. If you have one web client, one backend team and a handful of endpoints, a good backend engineer with REST or tRPC will ship faster and you will maintain less. If your problem is that queries are slow, hire a Postgres person, not a GraphQL person. If your problem is that the frontend and backend keep breaking each other's contracts, that is a codegen and CI problem before it is an architecture problem.

When it is the right call, we staff it as a pair rather than a hero. One engineer owns schema design and the deprecation process, working directly with whoever knows your domain, because a schema is a business artefact and gets written badly when engineers guess. A second owns resolvers, batching, authorization and the performance budget, with tracing and query-count tests wired into CI from the first week so N+1 regressions fail the build instead of the app store review. If clients need integrating, we add a frontend engineer on fragments, codegen and cache policies for a shorter window. You own the repo, the schema and the registry from day one, and the handover we plan for is the one where your team keeps the graph, not the one where you keep calling us.