Forward-deployed engineering: why it works, and where it breaks

The usual bargain in enterprise software services is that you buy a recommendation. A team arrives, interviews forty people, and leaves behind a document. Some months later a pilot is built from that document by somebody else. The pilot works, in the sense that it works on the laptop it was built on. Then it meets the identity provider, the data retention policy, the team that owns the service it needs to call, and the person whose job it quietly changes — and it stops.

Nobody in that chain did anything wrong. The failure is structural: the people who understood the problem were never the people who had to make the thing run.

Forward-deployed engineering is the attempt to collapse that chain. It is not a new idea and it is not a clever one. It is the observation that if the engineer who designs the system is also the engineer who ships it, inside your environment, against your constraints, most of the usual failure modes never get the chance to happen.

What a forward deployed engineer actually is

A forward deployed engineer is a product engineer who works inside a customer's organisation — in their repositories, against their data, deploying to their production — rather than from a vendor's office against a written specification. They are embedded, they have commit rights, and they are accountable for whether the system runs, not for whether the advice was good.

The role came out of Palantir, where the problem was that the software was useless without deep knowledge of the customer's data and the customer's data was not something you could learn from a requirements document. The only way to build anything was to put engineers in the building. The AI labs now hire for the same title for the same reason: a model is a capability, not a product, and the distance between the two is entirely made of someone else's systems.

Three things separate it from the adjacent roles people confuse it with:

• A consultant produces a recommendation. Someone else builds it. The consultant's work is complete when the document is accepted.
• A staff-augmentation contractor builds what the client's backlog already says to build. They are a pair of hands with a rate card, and the scoping decisions were made before they arrived.
• A forward deployed engineer decides what to build, builds it, ships it to production, and is measured on whether it works there.

That last clause is doing all the work. Everything else in this essay follows from it.

Why the billing model is the whole argument

Here is the uncomfortable part, and it has nothing to do with AI.

If a services business bills for time, then a programme that runs long is not a failure. It is revenue. Nobody needs to be cynical for this to bite — no one sits in a room deciding to go slowly. It is simply that every small decision under time-and-materials has a thumb on the scale, and the thumb points the same way every time. Should we add a discovery phase? Should this be two workstreams? Should we staff a programme manager? Under hourly billing the answer to each is defensible, and the aggregate of a hundred defensible answers is an eighteen-month engagement.

Price the same work on what ships and every one of those answers inverts. A four-person squad that finishes early is now the point rather than a problem, because the team's margin improves when the thing is done.

The trade that makes it work for the buyer is also worth naming: outcome pricing transfers delivery risk to the vendor, and vendors do not take risk for free. You will not get the cheapest possible day rate this way. You get a bounded price for a defined result, which is a different thing to buy and a much easier thing to govern.

The loop

The shape of a good forward-deployed engagement is short and repetitive rather than long and linear. Ours runs like this.

Two weeks, ending in something that runs. No six-month discovery and no 200-slide deck. The audit ends with a working prototype and a ranked list of use cases with the ROI arithmetic attached to each. The point is not the prototype — it is that the decision about what to do next gets made against something running rather than something described. Teams argue very differently about a demo than about a slide.

Then the squad goes inside. Your repositories, your data, your production. Not a parallel environment that will need a migration later. Most of the hard-won knowledge in this work is about the specific, undocumented reasons your systems are the way they are, and none of that transfers through a specification.

Instrument the baseline before you change anything. This is the step everybody skips and the one that decides whether the engagement ends in a renewal or an argument. If you cannot state what the metric was before, "improved" is a matter of opinion, and outcome-based pricing without an agreed number is a dispute with a delay fuse.

Then rewire the workflow and train the people who have to live with it. A system that technically works and that nobody uses has not shipped. This is the part that looks like change management and gets treated as soft, and it is where most of the value either lands or evaporates.

Where it breaks

Any model is worth more if you know its failure modes, so here are the five that actually recur.

No production access. If the engagement is forward-deployed in name but the engineer is working in a sandbox with synthetic data and a quarterly release train, you have bought consulting with extra steps and a worse hourly rate. Production access is not a nice-to-have in this model; it is the model. If procurement and security cannot get there, say so at the start and pick a different arrangement.

No named owner on the client side. An embedded engineer makes a dozen small decisions a week that need someone with authority to confirm. Without one person who can say yes, those decisions queue, and a model whose entire advantage is speed loses its advantage. A steering committee is not an owner.

A mandate too vague to finish. "Help us with AI" cannot be delivered, only occupied. The scope does not need to be large, but someone has to be able to describe what done looks like in a sentence. If nobody can, the first two weeks should produce that sentence and nothing else.

Outcome pricing with no instrumented baseline. Covered above, and worth repeating because it is the most expensive one. Agree the number before the work, in writing, including how it will be measured and who measures it.

An engagement that never ends. This is the subtle one. An embedded team that becomes load-bearing has stopped transferring capability and started selling dependency — and it is comfortable for both sides, which is exactly why it persists. A good forward-deployed engagement has an exit condition stated at the start: the client's own engineers own the system, and the squad is gone. If your vendor has never once argued themselves out of scope, that is information.

Six questions for a vendor who says they do this

Worth asking before signing anything. The answers separate the model from the vocabulary.

1. Will your engineers have commit access to our repositories, or will they hand us patches?
2. What ships in the first two weeks, and will it be running or described?
3. How is this priced — by hours, by milestone, or by outcome? If by outcome, what is the number and who measures it?
4. Who on your side is accountable when it is in production and it breaks at 2am?
5. What is the exit condition, and who owns the system afterwards?
6. Name something you argued your way out of building for a previous client.

The sixth is the one that is hard to fake. A vendor who has never talked a customer out of scope is either very lucky or paid by the hour.

What this looks like as a business

markai is built this way, which is the reason this essay is on this site rather than somewhere disinterested. We sell outcomes rather than headcount, we price on what ships, and the same engineers who scope the work are the ones in your repository. The three stages above — the two-week audit, the embedded squad, the instrumented baseline — are the whole offer, and there is no fourth stage where a larger team arrives.

To first running prototype

2 weeks

Typical squad

4 people

Priced on

Outcomes

The same discipline produced our second line of work. Pricing teams in airlines, hotels and retail kept asking for the same thing — competitive fare and rate data, clean enough and quick enough to reprice against the same morning — and it turned out to be a harder engineering problem than any of them expected. That became a product rather than an engagement: air fare intelligence and hotel rate intelligence, delivered by API.

Both of those are worth reading if you want the unglamorous version of what embedded work actually involves. Airfare data is not a price and nobody names a room the same way twice are both essentially field notes on how far a problem can be from its description.

---

If you want to talk about whether this model fits what you are trying to do — including the case where it does not — that conversation is free.