How to hire a RAG developer who ships more than a demo

The hard part of hiring a RAG developer is that almost anyone can build the version that demos well. Embed some documents, drop them in a vector store, stuff the top matches into a prompt, and you have a system that answers the three questions you tested it on. The person you actually want to hire is the one who makes it correct on question forty — the off-distribution question where a weak system pulls a stale paragraph and confidently invents an answer that was never in your documents.

That gap is the entire discipline, and it's invisible in a demo. Below is what separates a production RAG build from a prototype, a comparison of who you can hire and what each is good for, honest cost ranges, the red flags that tell you someone only knows the demo, and where Duskel fits. If you want the pricing angle in depth, we wrote a companion piece on what a RAG system costs to build.

What separates a production RAG build from a demo

A demo proves the model can talk. A production system proves it stays right across the weird inputs real users provide, and refuses when it doesn't know. The difference lives almost entirely in the retrieval half and the testing around it — not in which model you plug in at the end. When you interview a RAG developer, these are the things a real one brings up before you do:

• Retrieval quality first. A hallucination is usually a retrieval miss wearing a generation costume. The skill is making the right chunk land in the top results every time, not swapping one model for another.
• Structure-aware chunking. Splitting on the document's own structure — headings, list items, table rows, clauses — instead of blind fixed-size windows that cut a table in half and strand a definition three chunks from the term it defines.
• Hybrid search. Pairing dense vector search with keyword search like BM25 so the system stops fumbling the exact-match cases — error codes, SKUs, proper nouns — that embeddings routinely miss, then reranking the wide candidate set into a good one.
• Guardrails that let it refuse. A calibrated confidence gate so that when nothing crosses the bar, the answer is "I don't have that information" rather than a fluent guess. A system that can refuse is worth more than one that always answers.
• Evals as a deliverable. A golden question set that scores retrieval and generation as separate numbers, plus a regression check that fires when someone swaps the model or edits a prompt. "We'll try it and see" is not a quality bar you can ship on.

If a candidate's plan for measuring quality is a vibe check, you're paying senior rates for a prototype. We go deeper on the mechanics in how to build a RAG system that doesn't hallucinate.

Freelancer vs agency vs specialist studio

Who you hire matters more than the hourly rate, because the failure modes only surface weeks in. Here's an honest read on the three options against the things that actually decide whether a RAG system survives contact with real data.

What it costs to hire

Rates track experience with the failure surface, not raw hours. Here's roughly what the market looks like in 2026, and how a scoped project engagement compares to hiring by the hour or full-time.

The expensive, invisible line item isn't the build — it's the loop after launch. Models get deprecated on 90 days' notice, your documents change, and users ask things nobody scripted. If a quote never mentions ongoing evaluation and observability, it's either underpriced or written by someone who has never watched a model quietly lose accuracy overnight.

Red flags when hiring a RAG developer

You can spot a wrapper in one conversation. Watch for these:

• They talk about the model choice first and retrieval never — the model was rarely the weak link.
• Their plan to measure quality is "we'll test it by hand." No golden set, no regression check, no separate retrieval score.
• They chunk by fixed character count and can't explain why structure-aware chunking matters.
• No mention of a refusal path — the system will always answer, which means it will confidently lie.
• They reach for a fine-tuned or custom model before fixing retrieval, the single most common way to waste a RAG budget.
• The demo answers cherry-picked questions and they get defensive when you bring your own documents to test.

Why Duskel — RAG that survives real data

We build RAG systems for the question the demo never shows: the off-distribution one where a weak system invents an answer. That means structure-aware chunking, hybrid retrieval with reranking, a calibrated confidence gate so the system refuses instead of guessing, and checkable citations that turn hallucination from an invisible failure into something you can measure and regression-test.

We're a studio that ships production software and runs its own products, so the eval harness is a deliverable, not an afterthought — you get a system you can trust and, if you want it, an internal team ready to inherit it. No fabricated case studies here; what we'll do is take your actual documents and show you where retrieval holds and where it breaks before you commit. Tell us what you're building and we'll scope it against your real data.

FAQ

Want a RAG system that stays right on your real data, not just the demo? Let's scope it.

Send the problem. You get one fixed number and a plan back within a business day.