Hiring GenAI Consulting: A Buyer's Guide

Last month a US founder asked me a question I get almost every week: "We have budget for a GenAI consultant. How do we not waste it?" His last engagement burned $80k on a demo that never made it near production. Nobody was lying to him. He just didn't know what he was buying.

This is the guide I wish he'd had. I've been on both sides of these conversations: pitching, delivering, and sometimes cleaning up after other people's proofs of concept. What follows is how I'd hire a generative AI consultant if I were writing the check.

What you are actually buying (and what most buyers think they are buying)

Most buyers think they are hiring "an AI expert." What you are actually buying is one of four very different things, and confusing them is the single biggest reason engagements fail.

The four buckets I see:

1. Strategy and advisory. Someone who sits with your team, maps use cases, prices them, and helps you decide what NOT to build. Deliverable is a document and a decision.
2. Proof of concept (PoC). A working demo on synthetic or sample data. Deliverable is a Loom video and a repo. It is not production. It should never be presented as production.
3. AI MVP / production build. A real system that real users touch. Auth, logging, evals, a deploy pipeline, an on-call story. Deliverable is uptime.
4. Embedded / fractional AI engineer. Someone who joins your team part time for 3 to 12 months, ships code, and transfers knowledge. Deliverable is your team's capability after they leave.

If your consultant is pricing bucket 2 but you think you are buying bucket 3, you will end up angry in month four. Ask directly: "Which of these four am I paying for, and what does 'done' look like?"

Realistic pricing tiers in 2026 (USA and remote)

I'll give you the ranges I actually see across US and EU/remote GenAI consultants who can point to shipped production work. These are ballparks, not quotes. Skills, complexity, and IP terms move them a lot.

Two things to notice.

First, the remote discount is real but shrinking. A senior GenAI engineer in Belgrade, Warsaw, or Lisbon working US hours now costs roughly 60 to 70 percent of a US onshore equivalent, not the 30 percent people expected in 2020. Good people know their market.

Second, agency pricing is not senior-engineer pricing times headcount. You are also paying for account management, sales overhead, and bench risk. Sometimes that is worth it. Often it isn't, especially for a PoC where you want the actual builder in the room.

If someone quotes you $500k for an "AI agent MVP" with no scoping doc, that is not a price, it's a hope. My rule: no fixed price should exist without a written scope, a data audit, and at least one working spike. I wrote more about how I scope this on the blog, and the reality of MVP cost is worth its own read.

Engagement models: which one actually fits your situation

The engagement model matters more than the hourly rate. I've watched teams pay a premium for the wrong shape of contract and get a worse outcome than a cheaper, well-matched one.

Fixed price, fixed scope

Works when: the problem is bounded, the data is understood, and you don't expect requirements to change. RAG over a known document set. A classifier with a defined taxonomy. A specific workflow automation.

Fails when: it's exploratory. GenAI work has irreducible uncertainty. If your consultant agrees to a fixed price for something they've never done before, one of you is going to lose, and it's usually going to be you (because they'll build the cheapest thing that satisfies the contract).

Time and materials with a not-to-exceed cap

My default for real production work. Weekly invoicing, transparent hours, hard ceiling. You get flexibility, they get protection, and the cap forces honest conversations when scope expands.

Retainer / fractional

Best for teams that have some in-house engineering but need a senior GenAI brain 1 to 3 days a week. This is where I see the highest ROI right now, because you avoid the "consultant leaves and nobody understands the LangGraph state machine" problem.

Outcome-based

Rare, and I'm skeptical of it for GenAI. "Pay us when accuracy hits 92 percent" sounds great until you argue about what accuracy means on which slice of data. I've seen exactly one outcome-based deal work cleanly, and it was a narrow document extraction task with a labeled golden set the client owned.

Remote vs US onshore: the honest trade-offs

I'm a remote consultant based in Belgrade working with US and Western European clients. So take my view with the appropriate salt. Here's what I actually see:

Where onshore wins:

• Regulated industries (healthcare, defense, some finance) where data residency and clearances matter
• Deals that require on-site workshops for stakeholder alignment
• Teams that have never worked async and won't learn fast
• Anything under a 3-week timeline where friction cost outweighs rate savings

Where remote wins:

• Cost, obviously, but often less than you think
• Access to a much wider senior talent pool. The US market for senior GenAI engineers is brutally thin. Remote opens EU, LATAM, and select APAC talent that has actually shipped production LLM systems.
• Overnight progress on well-scoped tasks when there is a partial timezone overlap

The real filter is not geography, it's overlap and communication. A remote engineer with 4 hours of US overlap, strong written English, a Loom-first culture, and a habit of end-of-day written updates will out-deliver an onshore engineer who shows up to standup and disappears. Ask for a work sample and a written status update from a past engagement. Not a testimonial. The actual artifact.

How to vet for real production experience (not demo theater)

This is the part where most buyers get burned. The GenAI space is full of people who can wire together a LangChain demo in a weekend and call themselves a consultant. Here's how I'd separate demo builders from production engineers.

1. Ask about evals, not models

Any senior GenAI engineer will talk about evaluation before they talk about model choice. If the first thing out of their mouth is "we'd use GPT-5 / Claude / whatever," you're talking to someone who read the docs. If they ask "how will we know it's working, and who owns the labeled test set," you're talking to a builder.

Good follow-ups:

• "Walk me through the eval harness on your last project."
• "How did you catch regressions when you changed a prompt?"
• "What was your accuracy on the initial baseline vs. what shipped?"

2. Ask what broke in production

Every real system has broken in embarrassing ways. Rate limits, hallucinations that reached users, a vector index that got out of sync, a runaway agent that spent $400 in one afternoon. If your candidate can't tell you a specific war story with a specific fix, they haven't run one in production.

I'll tell you mine: I once had a content agent that, due to a tool-call parsing bug, published a draft with a placeholder title. Reader saw it before I did. Fix was a hard schema validation gate before publish plus a synthetic canary that runs the full pipeline every hour on a throwaway site. Boring, effective, and the kind of thing you only learn by getting bitten.

3. Look at the boring parts of the repo

Ask to see (with redactions) a real project repo. Skip the model code. Look at:

• CI/CD, deploy scripts, infra as code
• The eval directory (does one even exist?)
• Logging, tracing, cost tracking
• The README and runbook

If the interesting code is a Jupyter notebook and there's no infra/ folder, that is a research prototype, not a production system.

4. Ask about cost and latency budgets

"What was your per-request cost target, and how did you hit it?" A production GenAI engineer thinks in dollars per thousand requests and p95 latency. They know when to route to a small model, when to cache, when to use structured outputs to shrink tokens. A demo builder does not.

5. Ask who owns the code and the weights

This should be in writing. Who owns the code you pay for? Who owns fine-tuned model artifacts? What happens to your API keys and data at contract end? If a consultant hedges here, walk.

Red flags I'd walk from

Short list, in no particular order:

• No written scope before the SOW. You'll pay for the ambiguity.
• "We use our proprietary framework." Sometimes fine, often a lock-in trap. Ask what you get if the engagement ends.
• All senior in the pitch, all junior on delivery. Common with agencies. Get the actual builder's name in the SOW.
• No mention of evals, guardrails, or observability. They will hand you a system you cannot safely change.
• Fixed price on unfamiliar territory. Either you or they will lose.
• They can't tell you about a project that failed. Everyone has one. People who claim otherwise are either new or dishonest.
• They can't explain their answer without jargon. A good consultant can explain RAG or an agent loop to your CFO in three sentences.

What I'd do if I were writing the check

If I were a US founder or CTO hiring GenAI help today, here's my playbook:

1. Start with a 2-week paid scoping engagement, not a PoC. $10k to $20k. Deliverable is a written architecture, a data audit, a build/buy analysis, and a phased plan with real numbers. If they can't do this well, they cannot build the thing.
2. Then a bounded PoC, 3 to 4 weeks, with a written success metric agreed up front. Not "it works" but "it hits 85 percent on this 200-example test set at under $0.03 per request."
3. Only then decide on production build, and prefer a T&M contract with a cap and weekly demos.
4. Insist on knowledge transfer from day one. Recorded walkthroughs, a runbook, and a written handoff plan. If your team can't operate the system without the consultant, you didn't buy a system, you bought a dependency.
5. Prefer one senior over a team of three mid-levels for anything under 6 months. The coordination tax on small GenAI projects is brutal.

The best engagements I've been part of, on either side of the table, share one trait: the buyer knew what "done" looked like before we started, and we both wrote it down.

Closing

Hiring GenAI consulting well is mostly about clarity. Clarity on what you're buying, clarity on what done looks like, clarity on who's actually going to write the code. The rest is just diligence you'd apply to any senior technical hire.

If you're a founder or CTO working through a hire like this and want a second pair of eyes on a scope, a proposal, or a shortlist, I'm happy to talk. You can reach me at lazar-milicevic.com/#contact, or read more field notes on the blog.