Why the Forward Deployed Engineering Model Works for Mid-Market AI

The forward deployed engineering model works because it removes the handoffs that kill mid-market AI projects. Instead of a strategy firm writing a plan, an offshore team building against it, and your engineers integrating whatever arrives, one small team of engineers embeds in your environment and owns the problem from assessment through production. Fewer handoffs means less information lost, and in AI work the information that gets lost between stages is precisely the information that decides the outcome. For a company with a capable but stretched engineering team and no prior AI production experience, this is the delivery model with the best odds.

Here is why the alternatives break down, and what the model actually looks like week by week.

Related reading: what a forward deployed engineer actually does, why AI pilots fail, and a pilot-to-production checklist.

The mid-market squeeze

Large enterprises solve AI delivery with money. They hire a strategy firm, stand up an internal platform team, run a centre of excellence, and absorb the cost of the failures. Startups solve it with proximity: four engineers in a room who all understand the product and the data, shipping in days.

Mid-market companies get neither. They have real revenue to protect, real data complexity and real compliance obligations, so the startup approach does not fit. They do not have a spare platform team or a tolerance for eighteen months of overhead, so the enterprise approach does not fit either. What they typically have is a good product engineering team that is fully committed to the roadmap and has never shipped an AI system to production.

The result is the pattern we see constantly: the strategy work gets done, the use case gets agreed, everyone is aligned, and nothing reaches production. Not because anyone is bad at their job. Because nobody has the bandwidth and the specific experience at the same time.

Why the standard delivery models fail here

Strategy engagement then separate implementation. The people who wrote the plan never had to live with it. The plan is validated by argument rather than by contact with your data, so its wrong assumptions surface at the most expensive possible moment: months later, mid-build. This is the single most common shape of a stalled mid-market AI programme.

Staff augmentation. You get engineers, but the accountability stays with you, and if your bottleneck is "nobody here has done this before," adding hands does not supply judgment. Contractors will build what you specify, including the parts that are wrong.

Buy a platform. Sometimes correct, and worth taking seriously before you build anything custom. But the platform still has to be wired into your data and your workflow, and that integration is where the work actually is. Many companies buy the tool, skip the workflow redesign, and end up with a licence and no change in the numbers.

Do it internally, later. The most common choice and the most expensive. It is not really a decision, it is a deferral, and the roadmap never opens up.

What the evidence says the bottleneck is

MIT found that 95% of AI pilots deliver no measurable business impact. RAND has put the AI project failure rate at roughly 80%, around twice the rate of other IT projects. McKinsey's recurring finding is that redesigning the end-to-end workflow is the single biggest driver of value from AI, ahead of model or vendor choice.

Put together: the technology works, the delivery does not, and the specific thing that goes missing is workflow redesign. That is not a problem you solve with a better model or a longer plan. It is a problem you solve by putting engineers close enough to the workflow to redesign it, which is the definition of the forward deployed engineer role.

What the model looks like in practice

A typical engagement runs in four movements. The shape matters more than the calendar.

Weeks 1 to 2: get to the real problem. Sit with the operators, read the actual tickets, and touch the actual data. Assume the scope written before anyone opened the warehouse is wrong in at least one expensive way, and find out which way early while the scope can still change. Half the value of the model is delivered here, before anything is built.

Weeks 2 to 5: build the thinnest thing that touches production. Not a polished prototype in a sandbox. A scrappy, instrumented version running against real data with real edge cases. The goal is to meet the ugly parts of the environment as early as possible, because every week you delay that meeting is a week of building on assumptions.

Weeks 5 to 10: harden and instrument. Evals, guardrails, monitoring, cost and latency work, and a dashboard showing a business number rather than a model score. If nobody can say what number moved, the work did not happen. The pilot-to-production checklist covers what has to be true here.

Weeks 8 onward: hand it over deliberately. Train the team who will run it, write the runbook, sit through the first weeks of production weirdness. A system your team cannot operate is a liability the vendor left behind, not an asset.

Why proximity beats process

The argument for forward deployed engineering is not that embedded engineers are smarter. It is that they are exposed to information that no process can transmit.

The field that everyone treats as reliable and that has been null for 14% of rows since a migration last March. The operator who has quietly worked around the official process for two years, so the workflow in the documentation is fiction. The seasonal pattern that makes your evaluation set unrepresentative. The internal politics that mean the team asked to adopt this had a competing tool taken away from them last year and are not going to be enthusiastic.

None of that appears in a requirements document. All of it decides whether the system works. You cannot process your way to it. You have to be there.

This is also why the model resists scaling in the usual way. An FDE holds one or two engagements at a time because the context does not survive being split five ways. That constraint is the model working correctly, not a limitation to be optimised away.

When it is the wrong choice

Honesty about the boundaries, since a firm arguing for its own model should say where it stops.

You do not need forward deployed engineering for a well-documented integration your team has done variants of before. You do not need it when the right answer is genuinely to buy an off-the-shelf tool and configure it, and a good partner will tell you when that is the case. And it is a poor fit if your organisation cannot give an outside team real access to systems and people, because the entire advantage is proximity. If security or politics mean the engineers will be held at arm's length, you will pay embedded rates for contractor outcomes.

Frequently asked questions

How is this different from just hiring contractors? Contractors build what you specify and the accountability stays with you. A forward deployed team is accountable for the outcome, which includes telling you when the specification is wrong. If your bottleneck is capacity, hire contractors. If it is judgment plus capacity, that is a different purchase.

Does this work with a remote team? Yes, with overlapping hours. Embedding means working inside your systems, standups and decisions rather than physical presence. Occasional travel helps at the start of an engagement and when a difficult conversation needs a room.

How long before we see anything in production? Something instrumented should be touching real data inside the first month. If week four arrives and nothing is running in your environment, the engagement has quietly turned into consulting, and that is the moment to say so.

What happens when the engagement ends? Your team runs the system. That is the design goal, and it is why handover is a phase with real time allocated to it rather than a final email. Ask any prospective partner what their handover looks like before you sign.

Is this more expensive than traditional consulting? Per hour, usually yes. Per outcome, it is the comparison that matters, because the deliverable is a running system rather than a recommendation. See what a real AI consulting engagement costs for how we think about pricing.

10dem runs this model by default. If your AI work is stuck between the plan and production, tell us where it is stuck or read more about how we work.