What is a forward deployed engineer?

A forward deployed engineer is an engineer who works inside your company instead of at a vendor. They use your data, your systems and your rules, and they are responsible for getting the system running in production, not for writing a recommendation.

I do this job. This page explains what it is, where the name came from, what the work looks like day to day, and when you should not hire one. The examples are from my own engagements, with names removed.

Where the term came from

Palantir used it for engineers who were sent to work on site with a customer, usually a government department or a big company, and build directly on that customer's data instead of shipping a generic product and hoping it fit. People in the industry joked that Palantir was a consultancy pretending to be a software company. The engineers doing the job knew it was neither. They were building a product, but starting from one customer's problem.

The term came back with AI because the same problem came back. A language model is a general tool. The value is in connecting it to your invoices, your claims process, your customer history. That connection is where AI pilots fail. The labs worked this out and started hiring engineers to work directly with customers. Most other companies worked it out by watching a pilot impress the board and never go live.

So today it is mostly an AI job. Not because the engineer trains models. Almost nobody does. The model is the easy part. The hard part is making it correct inside one company: what it is allowed to read, what it must never say, what happens when it is wrong, who checks it, and how it gets into the system your staff already use.

The job is not owned by any one company. It is a way of working. The rest of this page is what it looked like when I did it.

A mistake from my first week, and why it matters

Early in one engagement I sent the owner the first automated cut of a video. The presenter was talking about the downtown area, and the drone footage under his voice showed streets, rooftops and water. It looked fine to me. He watched it once and said: that is not downtown, that is the other side of the river.

He was right. The pipeline was an AI system. A speech model transcribed the presenter, a language model read the transcript and decided what each moment should show, and another model wrote the on-screen graphics. All of that worked. The part that failed was mine. I had grouped 112 drone clips into neighborhoods by GPS distance, and the two areas are close enough on a map that a simple grouping puts them together. There is a river between them. Anyone who lives there knows the difference immediately. No model, and nobody from outside, could have caught it from the coordinates.

I use this example because it is ordinary, and because it shows the two things the job depends on. I was close enough to the owner's work that the correction came in the first week, not after launch. And I fixed the cause, not just that one clip: proper boundary polygons and point-in-polygon tests, written that afternoon, with a note in the project's learnings file so it never happens again.

The first thing you write is not code

The first document on every engagement I have run is a list of decisions that are not mine. On the engagement above it was a file with a section called "founder decisions, do not relitigate". Nine lines. Which data source is in and which is out. No phone calls to customers, ever. Which segment first, which later. Which platforms get budget. Even which AI model to use.

Next to it were the owner's operating rules. No live change to the domain or the running site without his OK. Keep the analytics exactly as they are. Plain English in anything he reads.

I used to see lists like this as something that slowed me down. Now I think they are the most useful thing an owner can give me. Each line is a decision I don't have to make, defend or reopen, and a limit the owner doesn't have to enforce. On my own projects I rebuild things whenever I want. One of them went from version one to version two with 238 commits thrown away after six days. Inside someone else's business you can't do that, and the list is what lets you move fast without doing it.

What a normal week looks like

The AI models in that pipeline (transcription, planning, graphics) took almost none of my time. Most of each week went into the work around them. Here is one week from my notes. It is typical.

• The first automated edit put the audio out of sync. I had joined the presenter footage and the drone clips into one timeline. Joining adds each clip's length to the video, so by the first cutaway the voice was behind the picture. The fix was to lay the clips over the presenter track for a fixed window instead, which leaves the audio alone. It cost one evening. The rule I wrote down: place clips over the track, don't add them to its length.
• A quality setting turned a 439 MB file into 1.87 GB. The encoder's "best" preset. Switching to the normal preset gave 247 MB, and nobody could see a difference. The number and the reason went in the decision log so the next person doesn't repeat the test.
• Uploads over 100 MB were failing. Not a video problem. The proxy in front of the app timed out before the file finished uploading. Signed upload links straight to storage fixed it and made every upload faster.
• The database got corrupted when the host restarted the container. The hosting platform kills containers without warning. Turning on full synchronous writes cost a little speed and ended the corruption. You can't choose the client's hosting, so the system has to work with how it behaves.
• The render took fourteen minutes. Eleven chunks encoded one after another. Encoding them at the same time brought it to about two minutes. Removing an option the merge step didn't need halved the merge on top of that, 90 seconds to 38.

None of this is advanced work. It gets done only because a real person is waiting for the render, and fourteen minutes is fourteen minutes of their working day. That is the difference between a deployment and a pilot: most pilots never get to this stage.

Platform rules, credentials, and other things you don't control

The constraints that cost the most time were not technical and were not mine. They belonged to the platforms we published to, the vendors we depended on, and the customer's own approval process. You only find them by trying to publish.

On that engagement the product had to publish to five platforms. Each has limits you only discover when something fails. One refuses any link that is signed or expires, so the whole media store had to serve plain public URLs or nothing would post. One caps unverified accounts at fifteen minutes of video, so a full-length upload fails without saying why. One shows a post to far fewer people when it contains a link. One takes no video at all and archives posts after about a week. I wrote every one of them into a playbook with a mark next to it: works as is, needs a change, can't do. Most of the "needs a change" items turned out to be the same three jobs, done once and reused.

Then there are credentials. The customer's keys, accounts and sign-offs are the slowest part of any engagement. So I build the system so it never has to wait for them. Every external service gets a real implementation and a stand-in, and the code picks one based on whether the secret is present. On one product that meant the whole system, 127 unit tests and 179 endpoint tests, passed with no cloud account and no vendor keys at all. When the keys arrive, one environment variable turns the real service on. This sounds obvious. Most projects I have seen don't do it, and they spend their second month waiting.

The handover is the deliverable

An engagement that ends with a running system but no handover is not finished, even if it has been invoiced.

The handover documents from that engagement, ten of them across four codebases, are written like contracts, because both sides have to be able to rely on them. Each one says who it is from and to, what shipped and with which commit, what was deliberately not built and why, and a numbered activation list that names who does each step. You hand over these DNS records. The owner adds them. You verify the domain. The owner sets these two secrets and redeploys. The owner triggers one real event. You confirm it arrived. One of them ends with a step people tend to skip: re-issue this key, because the current one was pasted into a chat.

Handing over means a document that someone who was not involved in the project can follow, not a training session.

What the role is not

It is not consulting. A consultant gives advice. Your team implements it, or doesn't, and the consultant is rarely there when it fails. I was there, which is why the owner told me about the river mistake directly.

It is not a solutions engineer (the full comparison with sales engineers and solutions architects is on its own page). A solutions engineer works before the sale, showing that a product could solve your problem, usually on demo data. A forward deployed engineer works after the sale, making it solve your problem on real data, and is accountable until it runs. Similar skills. The difference is when they work and what they are accountable for.

It is not an agency. An agency scales by putting more people on more clients and standardizing what it delivers. This work does not standardize, because it is shaped by one company's data and rules. It scales by leaving your team able to run the system without the engineer.

And it is not only writing code. On a retail platform I led for nineteen months, a live merchandising operation with purchase orders, cost of goods, stock transfers between stores, and integrations into the point of sale, the accounting system and the shipping carrier, a team of seven built on the design I set up. I owned the architecture, the split between the transactional database and the analytics store, the AI layer that turned sales and stock data into answers, and every integration into the systems the business already ran. The role is making the design decisions and building the connections between systems. Writing most of the code is what a team is for.

When you should not hire one

I sell this way of working, so read this section with that in mind. These are the cases where I would tell you not to hire me.

• You haven't decided what you want solved. A forward deployed engineer hired in that situation will spend the engagement finding the missing decision, at engineer rates. A short advisory piece first is cheaper and more honest.
• Nobody inside will own the system afterwards. If there is no person who will run it after handover, nobody maintains the system after the engineer leaves.
• The data can't be reached in practice. Not "we have the data" but "an engineer can read it this week, with permission". If the answer is a procurement process, start the procurement first.
• What you want is a strategy document. Some boards need one. It is a different job.
• A product already does it. If something on the market does the job with the integrations you need, buy it. The forward deployed case is a problem that no product covers, inside your own process.

What to expect if you bring one in

1. You will be asked for decisions in week one, not code. What is in scope, what is out, what the engineer may not touch, who signs off on production changes. Write them down. The engineer will refer back to them later.
2. Something usable ships every week, through a real channel. Progress you can't see or use doesn't count. If a week produces nothing usable, you'll be told why in plain English.
3. Your people will catch things the engineer can't. That is expected. Have the person who knows the work review it from the first version.
4. The engineer builds around your slowest approvals so they are never waiting on you, and tells you exactly which key or record is needed and when.
5. The engagement ends with a handover you can run without them. If it doesn't, the engagement is not finished.

By industry

How an engagement runs week by week, from the records, is on its own page: forward deployed engineering, how it runs. The method is the same in every business. What changes is which process is worth building around. I have done this work in retail, real estate, media and ad platforms, robotics and inference, and I am writing up the opportunity in each industry as I publish the pages.

• AI in retail: what gets built inside a retail chain. Nineteen months inside a chain's operating platform: the reconciliation before any model, the forecast worked by hand, the order in which to try models, open-to-buy, and where AI is not worth it.

If you are the owner rather than the engineer, there is a version of all this written for you: what a forward deployed engineer does inside your company, the first month, the decisions that are yours, and what you own at the end. The two measured pieces below are the other proof a page like this can offer.

Common questions