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?"

A concrete example from earlier this year: a SaaS founder came to me after paying $120k to an "AI agency" for what he thought was a production customer support agent. What he actually got was bucket 2 dressed up as bucket 3. There was no eval set, no cost dashboard, no CI, and the "agent" was a single 400-line Python file running in a screen session on an EC2 box. The agency wasn't dishonest exactly — they had just sold him a PoC price with a production label. That mismatch cost him a quarter of runway.

The bucket-mismatch matrix

To make this concrete, here is what I see mispriced most often:

If the shape of the deliverable does not match the shape of the invoice, stop and rescope before you sign.

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 for AI consultant pricing, 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. Generative AI consultant rates have compressed globally because good people know their market and inbound demand is high.

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 AI MVP cost is worth its own read.

A quick rule of thumb for AI MVP cost

If you want a back-of-envelope for LLM production build cost, I use this:

• Base engineering: senior blended rate × 10 weeks × 1 to 2 engineers. That is 60 to 80 percent of the number.
• Infra and model costs during dev: typically $2k to $10k. Claude / GPT / embedding calls in dev and eval runs add up faster than people expect.
• Eval and data work: 15 to 25 percent of engineering time. If your consultant hasn't budgeted for this, they are not building a real system.
• Buffer: 15 percent. Always.

A "$100k MVP" that skips the eval and data line is a $100k PoC with delusions.

What the ongoing bill actually looks like

Buyers almost always underestimate the recurring cost after launch. A rough monthly picture for a mid-sized customer-facing LLM app doing a few hundred thousand requests per month:

• Model inference: $500 to $8k, depending on model tier, caching, and how aggressively you route to smaller models
• Vector DB / retrieval infra: $100 to $1.5k (managed) or the ops cost of self-hosting
• Observability (traces, evals, dashboards): $200 to $1k for tools like Langfuse, Braintrust, Arize
• Serverless AI architecture (Lambda, Cloud Run, queues): $100 to $2k
• Fractional AI engineer on retainer for the first 3 to 6 months post-launch: $8k to $20k/mo

Ask your consultant to write out these lines before signing. If they can't, they've never operated one of these systems past launch day.

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 AI consulting engagement 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. A fractional AI engineer is where I see the highest ROI right now, because you avoid the "consultant leaves and nobody understands the LangGraph state machine" problem. You get continuity, code review on your team's AI PRs, and a person who is around when the production agent starts hallucinating on a Tuesday afternoon.

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.

Equity or reduced-cash-plus-equity

Getting more common with early stage founders trying to hire an AI engineer. Sometimes fair, often abused in both directions. My heuristic: if a consultant will work purely for equity, they are either desperate or already overcommitted. A blended deal (60 to 80 percent cash, small equity) can align incentives, but only if you'd want them on the cap table anyway.

Pick-the-model cheat sheet

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 on remote AI engineer hiring 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 when hiring AI consultants.

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?"
• "What percentage of your production traffic do you replay through evals when you change a model or prompt?"

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.

Another one, more recent: an agentic workflow doing web research got into a tool-call loop where it kept re-fetching the same URL because the retriever returned near-duplicates ranked slightly differently on each call. Cost spiked 6x in a day. Fix: a dedupe on canonical URL at the tool boundary and a per-run tool-call budget that hard-fails at N calls. Every serious agent I build now has that budget wired in from day one.

A third, because it comes up in almost every enterprise AI automation project: a RAG pipeline over a client's SharePoint corpus started returning stale content two weeks post-launch. Nobody had wired up incremental re-indexing on document updates. Fix was a change-data-capture job on the source and a "freshness" field baked into retrieved chunks so the LLM could flag its own out-of-date answers. The lesson: retrieval is not a one-time build, it's a pipeline you own forever.

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
• How prompts are versioned (are they in git with tests, or hardcoded strings?)

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.

Concrete numbers I'd expect to hear from someone who has actually shipped: prompt-caching hit rates, a rough cost-per-conversation, a plan for handling the long-tail 99th percentile request that spends 40x the median. If they've never measured any of that, they've never had to.

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. This gets messier with agentic systems where the "IP" is often a set of prompts, tool definitions, and eval sets rather than a model. Name each artifact explicitly in the SOW.

6. Ask them to critique their own past work

"If you started that project over today, what would you do differently?" A senior AI implementation consultant will have a real, specific answer: they'd swap frameworks, they'd have built the eval set on day one instead of week six, they'd have picked a smaller model and skipped the fine-tune. A weaker candidate will tell you it was perfect. Nothing shipped is ever perfect.

7. Ask what they would NOT build with an LLM

This one filters ruthlessly. A good AI automation consultant will happily tell you which parts of your problem should be a regex, a rules engine, a SQL query, or a small classifier — not an LLM. If everything looks like a nail to them, you are hiring a hammer salesperson. The best custom AI agents for business I've built are 70 percent boring deterministic code and 30 percent LLM, not the reverse.

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.
• They pitch "AI transformation" instead of a specific workflow. Enterprise AI automation sold as vibes is a $500k line item that ships nothing. Ask which workflow, which team, which metric.
• No mention of humans in the loop for anything customer-facing in the first release. Confident autonomy on day one is a tell.
• Model name-dropping as differentiation. If the pitch centers on which frontier model they use rather than how they measure, evaluate, and operate the system, you're buying a wrapper.
• They don't ask about your data. Data quality, access, PII, and update cadence determine 80 percent of the outcome. A pitch that skips this is a pitch that skips reality.

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 for an AI proof of concept through production:

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.
6. Set a "kill criteria" up front. What result at the end of the PoC would cause you to shelve the project? Written down before you start. Without this, sunk cost will drag you into a bad production build.
7. Budget for a 90-day post-launch retainer. Fix the things that will only surface with real users on real traffic. Skipping this is how good MVPs quietly rot.

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.

A 30-minute vetting call, structured

If you get one 30-minute call with a candidate consultant, here is how I'd spend it. This maps directly to the vetting section above but forces you to leave with a decision, not a vibe.

• Minutes 0 to 5: They pitch themselves. Listen for whether they talk about outcomes and evals or about frameworks and models.
• Minutes 5 to 15: You describe the problem. Watch whether they immediately propose a solution (bad) or start asking about data, users, and current baselines (good).
• Minutes 15 to 22: Ask two specific vetting questions. Ideal: one about a production failure, one about cost/latency budget on a past project. Concrete answers with numbers or a shrug.
• Minutes 22 to 27: Ask about engagement shape. Do they push you toward the model that fits your situation, or toward the one that maximizes their revenue?
• Minutes 27 to 30: Ask what they'd want to see in a paid scoping engagement, and what they'd charge. If they can't answer without a follow-up call, they're not senior enough to run this.

If two or more answers were vague, keep looking. The talent pool of people who can build real LLM applications is thin, but it is not empty, and picking wrong is more expensive than waiting two more weeks.

A scoring sheet you can actually use

After the call, score them 1 to 5 on each of these. Anyone under 3.5 average is a pass:

• Talked about evals before models
• Asked about your data before proposing a solution
• Gave a specific production war story with numbers
• Named a project they'd redo differently and how
• Told you what they would NOT build with an LLM
• Was clear about who owns code, prompts, and eval sets
• Pushed back on your framing at least once

Consultants who score high on this rubric are almost always the ones you want. Consultants who score high on charisma and low on this rubric are the ones who leave you with a $120k EC2 screen session.

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.