When to Hire an AI Consultant vs an Engineer

Last month a founder emailed me with a 30-page strategy deck from a well-known consultancy. The recommendation: "explore agentic workflows for customer operations." Six weeks, mid five figures, and he still had zero shipped code. He asked me what to do next. My honest answer: you paid for a map when you needed a driver.

This is the mistake I see most often. Founders buy the wrong shape of help for the problem they actually have. So here is the framework I use when someone asks whether they need a consultant, an engineer, or something in between.

The four engagement shapes, and what each actually costs

There are really only four ways to buy AI help right now. Everything else is a marketing label on top of one of these.

Those numbers are what I see across the market in 2026 for genuinely senior work, not junior body-shop rates. If someone quotes you $200k for a "strategy phase" with no deliverable code, walk away. If someone quotes $8k for a production RAG system that handles sensitive data, run.

The rest of this post is about matching the shape to the signal.

Advisory: when you already have engineers and are burning cycles

Advisory is the right call when you have a technical team that is capable but stuck. They can write code. They cannot decide whether to use LangGraph or roll their own orchestrator, whether pgvector is enough or they need a dedicated vector DB, whether Claude or a fine-tuned open model makes more sense for their volume.

The signal is this: your engineers are asking questions that cost you a month each time they guess wrong.

A good advisory engagement looks like:

• A weekly 60-90 minute working session, camera on, screens shared
• Architecture decisions documented in a shared doc with trade-offs, not just conclusions
• Async availability in Slack for the fast questions ("does this eval design catch hallucinations?")
• A hiring pipeline review if you are recruiting AI engineers

What it does NOT look like: PowerPoint decks, "AI readiness assessments," or maturity model bingo cards. If your consultant is producing more slides than pull request comments, you are paying for theater.

I keep advisory retainers small on purpose, usually 4-8 hours a week. Beyond that, I am no longer advising, I am doing the work, and it should be priced as build or embedded.

POC: when someone needs to see it working before they say yes

A POC is not a demo. A demo is a scripted happy path. A POC is a real system running against real (or realistic) data, with a written evaluation that says "here is what it can and cannot do."

The signal for a POC is external: a board, an investor, an enterprise customer, or your own CEO needs evidence before they release budget or sign a contract. If nobody outside the engineering team is waiting on this, you probably do not need a POC. You need to just start building.

A POC I would ship in 3-5 weeks for around $20k-$35k typically contains:

1. A working pipeline against a real dataset (not toy data)
2. An eval harness with at least 50-100 labeled examples covering the important edge cases
3. Measured accuracy, latency, and cost per request
4. A written report on where it fails and what production-hardening would require
5. A live URL or CLI the stakeholder can actually poke at

The trap founders fall into: they pay for a POC, love the demo, and immediately assume it is 80% of the way to production. It is not. In my experience, a good POC is 20-30% of the total production build. The remaining 70% is retries, observability, guardrails, edge cases, cost controls, on-call, evals in CI, and the boring integration work.

When I write POC proposals I now include a paragraph called "What this POC will NOT be." It saves a lot of arguments later.

Build: when you know what you need and want it shipped

Build engagements are the cleanest. Scope is defined, success criteria are written down, and someone hands you working software at the end.

The signal: you can describe, in one paragraph, what the system needs to do, who uses it, and what "working" looks like. If you cannot write that paragraph, you are not ready for a build engagement. You are ready for advisory or a POC.

For an AI build, I want to see these things nailed before we sign:

• Data access: where does the source data live, what format, who owns the credentials
• Success metric: not "accurate" but "correctly classifies X within Y seconds on Z% of held-out examples"
• Failure mode: what happens when the model is wrong, who catches it, what the recovery is
• Deployment target: AWS Lambda, a container on your infra, a hosted API, someone's laptop
• Ownership after handoff: who runs it in month 4, do they have the skills

A real example from my own work: the serverless AWS + Zendesk integration I built delivered first-ever SLA compliance for the team using it. That was a build engagement, not a POC and not advisory. The problem was defined ("tickets are missing SLA targets, we need reliable enrichment and routing"), the metric was measurable (SLA %), and the deployment was clear (AWS Lambda + EventBridge). Six weeks, shipped, done. That is what a build looks like.

Where builds go wrong: scope creep dressed up as "iteration." If we agreed on three use cases and by week four we are discussing seven, we are no longer on a build engagement. We are on time and materials, and the price and timeline reset.

Embedded: when you are past experiments and need velocity

Embedded is the shape most founders under-use. It is when a senior engineer joins your team, usually 3-4 days a week, for a defined stretch of months. They are in your Slack, your standups, your on-call rotation. They ship code. They review your team's PRs. They mentor your junior AI engineers.

The signal: you have an AI product in production or close to it, you have a roadmap that is bigger than your team, and hiring a full-time senior AI engineer would take you six months.

Embedded is my favorite shape because it lets me actually own outcomes. I have seen the codebase. I have context on why a decision was made in April. I can push back on a bad plan because I know what breaks. Advisory gives directional input; embedded gives compounding improvement.

Cost-wise, embedded usually lands between $12k and $25k a month depending on seniority and days per week. That sounds expensive until you compare it to the fully-loaded cost of a senior AI engineer hire (salary + equity + recruiting + benefits + ramp time), which for the level of person you would actually want is $250k-$400k a year in most markets. Six months of embedded at $20k/month is $120k with zero ramp, zero recruiting risk, and a defined off-ramp.

The trade-off: an embedded engineer is not permanent. You will eventually need to hire, and part of a good embedded engagement is helping you do that (writing job specs, screening candidates, onboarding the person who takes over).

How to tell which shape you actually need

Here is the decision path I walk founders through when they call.

Start with the question: what would I do the day after this engagement ends?

• If the answer is "hand the recommendation to my team and they build it" → Advisory
• If the answer is "show the working thing to my board and get budget approved" → POC
• If the answer is "put this shipped system in front of customers next week" → Build
• If the answer is "keep shipping, this person is now part of how we operate" → Embedded

Then sanity-check against three signals:

1. Who has the pain? Internal team = advisory or embedded. External stakeholder = POC or build.
2. Is the problem defined? Fuzzy = advisory or POC. Sharp = build or embedded.
3. What is the time horizon? Weeks = POC. Months = build. Ongoing = embedded or advisory.

If two of these disagree, the honest answer is usually "you are not ready to buy help yet, we should spend 30 minutes on a scoping call before you sign anything."

Common mismatches and what they cost you

Some patterns I see repeatedly:

Buying advisory when you need build. You get a deck, an architecture diagram, and a bill. Six months later there is still nothing running because your team was already stretched thin, which is why you hired outside help in the first place. Cost: 6 months of runway and a demoralized team.

Buying build when you need a POC. You commit $80k to production before you know if the core technique even works on your data. Halfway through, evals show the model is 60% accurate when you needed 90%. Now you are renegotiating scope from a weak position. Cost: sunk-cost paralysis and probably a rewrite.

Buying POC when you need build. You already know it works, you have seen three vendors demo it, but you insist on "starting with a POC" out of caution. You spend 6 weeks and $25k re-proving what was already obvious, then still need to fund the build. Cost: 6 weeks and $25k of pure delay.

Buying embedded when you need advisory. You bring in a senior engineer 4 days a week when your team only really needed 4 hours a week of guidance. The engineer ends up doing work your team could have done, and your team learns less because someone else is shipping. Cost: 2-3x what you should have paid, plus atrophied internal skill.

What I'd do if I were the founder

If I were sitting on the other side of the table, this is how I would buy AI help in 2026:

1. Start with a paid 60-90 minute scoping call. Not a free discovery call, a paid one. You get better thinking and the consultant has skin in giving you the right recommendation, even if that recommendation is "you do not need us."
2. Never buy the biggest shape first. If in doubt between advisory and build, buy advisory for one month. If in doubt between POC and build, buy the POC. Cheaper to escalate than to unwind.
3. Write the success criteria before the contract, not after. If you cannot write them, that is the tell you need advisory or a POC, not a build.
4. Insist on shipped artifacts every engagement, including advisory. Decision documents, architecture diagrams, code reviews, hiring rubrics. If the deliverable is "we talked," that is not enough.
5. Ask for the off-ramp on day one. How does this end? What do we own? Who runs it in month six? A consultant who has thought about this is a consultant who plans to leave you in good shape.

The founder from the top of this post: we ended up doing a 3-week POC on his top use case for about $22k. It worked. Then he hired a full-time AI engineer, and I stayed on advisory for two months to help onboard them. Total spend was less than a third of the deck-only engagement, and he actually had a running system.

If you are trying to figure out which shape fits your situation, I am happy to talk it through. You can reach me at lazar-milicevic.com/#contact, or read more on the blog about what these engagements actually look like once you are inside them.