Forward Deployed Engineer: the engineer who replaces the consultant

The term comes from Palantir, which popularised it for an engineer sent to the client, into their offices, working with their real data, tasked with making the product work in context. The word “deployed” is military: you deploy someone into the field, not into a meeting room.

The role is now spreading beyond American software vendors, because AI has made the model viable at small scale. Here is what it actually covers, and when it fits a smaller company.

What a Forward Deployed Engineer does

An FDE writes code, but starts from the client’s problem rather than a ticket. A large share of the time goes into understanding the business: how the work is done today, where it jams, what data actually exists and in what condition.

The usual sequence has four steps:

1. Observe the process as practised, not as documented.
2. Build a narrow first version solving one specific case.
3. Put it in users’ hands within days, not months.
4. Fix based on real usage, then widen the scope.

What sets the profile apart is not technical skill. It is the refusal to separate the person who understands the problem from the person who writes the solution.

How it differs from a consultant and from an agency

The consultant produces analysis someone else must execute. The agency executes a spec someone else must have written correctly. The FDE removes the intermediary and absorbs the risk that the spec is wrong, which is the common case.

Why the model is becoming affordable now

Historically this model was expensive: a senior engineer, on site, for months. Only large organisations could fund it.

Two things changed.

The cost of a first version collapsed

Writing a working first version used to take weeks. With a coding assistant used seriously, that now takes days in many cases. It changes the nature of the conversation: you no longer discuss a mockup, you look at software running on the client’s data.

The cost of being wrong dropped

When a first version costs three weeks, you protect it, and you argue for months before writing it. When it costs three days, you throw it away without pain and start again. That shift is what makes the iterative model economically viable for a smaller company.

The consequence is counter-intuitive: AI did not make the developer redundant, it made the developer sitting with the client affordable. We put numbers on what that shift changes on a real project in what AI accelerates, and what it does not.

What it changes for a smaller company

Three differences show up within the first weeks.

The requirements document becomes optional. You no longer have to formalise upfront a need you only partly understand. The first version becomes the shared language, and it is what surfaces the real constraints.

Risk moves sides. A fixed price on outcome pushes the cost of estimation errors onto the supplier. It is also what forces that supplier to say no to requests that add nothing.

The rhythm becomes weekly. A weekly session with something visible replaces a monthly committee with slides. It is less comfortable, and far faster to correct.

When it is the wrong model

This way of working does not fit everything:

• When the need is fully stable and already specified, a traditional fixed-price supplier will cost less.
• When the main constraint is regulatory or contractual, the analysis phase does not compress, whatever the tooling.
• When an off-the-shelf product already covers eighty percent of the need, the right advice is to buy it, not rebuild it.
• When nobody on the client side can spend an hour a week on the project, the feedback loop never closes and the model loses its point.

That last point is the most underestimated. An FDE does not replace the availability of the business team: it depends on it.

A product shipped fast is worth little if nobody can find it. That is why visibility, and specifically GEO and citation by answer engines, is handled in the same motion as development. Our packages and prices are listed on the home page.

What a week looks like

The theoretical description shows little of the actual work. Here is the rhythm we hold on a typical engagement, and there is nothing exotic about it.

Monday, two hours with users. Not the decision-maker, the people doing the work. We watch over their shoulder while they handle a real case. That is where the parallel spreadsheets show up, the copy-pasting between two tools, the rules nobody wrote down. No scoping meeting surfaces that.

Tuesday and Wednesday, we build. The week's scope is deliberately small: one screen, one flow, one report. Enough to be usable, little enough to be thrown away without regret.

Thursday, it ships. To the real environment, with real data, reachable by the people we watched on Monday. It is the most important point of the week, and the one most projects push to the final quarter.

Friday, an hour of feedback. What got used, what got worked around, what is missing. The workaround is the most useful signal: it means the solution does not match the real work, and it is better learned in week two than in month six.

This cycle has a side effect we did not anticipate: user requests become sharper week after week, because people reason about something that exists rather than about an intention.

The skills that actually matter

The role is often framed as a senior engineering position. That holds for the technical part, but it is not where the difference is made.

Asking an open question

“What do you need?” produces a feature list, usually copied from an existing tool. “Show me how you do it today” produces a diagnosis. The first question costs months.

Being willing to throw away your own work

An engineer attached to their code slows the cycle, because they defend instead of listening. In this model part of the early work exists to learn and will be replaced. That is an accepted cost, not a failure.

Saying no with an argument

A fixed price on outcome forces you to refuse requests that add nothing, or you never ship. Refusing without explaining breaks the relationship; explaining the opportunity cost, by showing what would leave the scope in exchange, preserves it.

Knowing where your competence ends

On a regulated, accounting or medical subject, the engineer is not the expert and must not act like one. The role is then to translate faithfully a rule stated by someone else, and to have that translation validated.

How an engagement starts

We always follow the same order, because each step conditions the previous one.

1. A twenty-minute call. Context, pain, a quantified stake where possible. At the end we say whether the subject looks workable, and sometimes that it is not.
2. Half a day of observation. On site or over screen sharing, with the people concerned. This determines the real scope, often different from the announced one.
3. A quoted fixed price within forty-eight hours. One scope, one price, one date. No range, no day rates.
4. First release within one or two weeks. Narrow, real, usable.

If the second step reveals that an off-the-shelf product covers the need, we say so and the engagement stops there. It has happened, and it is the best possible use of half a day.

Key points

• A Forward Deployed Engineer starts from the observed business process, not a requirements document. The deliverable is software in production, not a recommendation.
• The model becomes affordable because a first version went from weeks to days, which makes being wrong cheap.
• Billing is fixed price per scope. Hourly billing penalises the fast supplier.
• The model fails when nobody on the client side can spend an hour a week on it: the feedback loop never closes.
• When the need is stable and already specified, a traditional fixed-price supplier costs less.