What a forward deployed engineer does, and when you need one

A forward deployed engineer (FDE) is a software engineer who works inside a customer's team instead of behind a product. They sit with the people who do the work, find the problems worth solving, and write the production code that solves them. Then they stay with it until it runs without them.

It's the job I do, so here's what it looks like up close, how it differs from the other ways to get software built, and how to tell if you need one.

Where the role comes from

Palantir made the role famous. Its engineers went out to customers and made the software work on the customer's real data and real problems, instead of waiting for a perfect product to do it for them.

AI has brought the role back. Models are good enough now that the hard part is rarely the model. It's the last mile: the messy inbox, the old CRM, the spreadsheet everyone depends on, and the person who knows the one rule that's written down nowhere. That's why AI companies like OpenAI and Anthropic use forward deployed engineers to get their models working inside real businesses.

What the work looks like

Most of my projects follow the same three steps.

1. Embed. I join your calls, your chat and your tools, and I watch the work happen. Not a workshop about the work, the work itself. Together we pick the jobs where AI saves the most time or money.
2. Build. I ship something real every week. Usually that's an AI agent or an automation wired into the systems you already run: email, CRM, documents, databases. Anything risky gets a check, and a person approves it before it goes out.
3. Hand over. Your team gets the code, the docs and a walkthrough. You own all of it, and nothing depends on me to keep running.

A typical week mixes all of it: a morning shadowing the support team, an afternoon wiring an agent into the ticket queue, and a Friday demo where the people who will use it try to break it.

How it differs from a consultant or an agency

A consultant tells you what to build. A forward deployed engineer builds it. The output isn't a deck, it's working software in production, with tests and monitoring.

An agency builds what's in the brief, from its own office, through a ticket queue. A forward deployed engineer works in your tools and your stand-ups, and changes the plan when the work shows the brief was wrong. With AI projects, it usually is, because nobody knows which jobs AI handles well until they try it on real data.

Hiring an in-house AI team is the right long-term move for some companies. But it takes months, and the first hire still has to learn your business. A forward deployed engineer starts shipping in the first week, and leaves your team able to run and extend what was built.

When you need one

You probably need a forward deployed engineer if one of these sounds familiar:

• You ran an AI pilot and it never shipped. The demo worked. Then it met real data, real edge cases and a real approval process, and it stalled.
• You know AI should help, but not where. Everyone has ideas, nobody has numbers, and no one has time to find out.
• The work is spread across systems. The job touches email, a CRM, shared documents and a database, and no off-the-shelf tool connects all four the way your team works.
• Mistakes are expensive. You need checks, approvals and a clear record of what the AI did, not a chatbot that's right most of the time.

When you don't

Sometimes you don't need one, and it's better to say so.

• An off-the-shelf tool already does the job. If a product does exactly what you need, buy it.
• You need new AI research. Training new models is a different job. Most businesses don't need it: the gains are in wiring good models into the work.
• Nobody can give the engineer access. The role only works when the engineer can see the real work and the real systems. If that's not possible yet, start there.

What good looks like at the end

When a forward deployed engagement ends well, you have:

• AI running inside your daily work, not in a separate demo.
• Evals that show how well it does the job, and alerts when that changes.
• Cost tracking, so you know what each workflow costs to run.
• Code, docs and training, so your team can change it without me.

That last part matters most. The goal isn't to become a permanent dependency. It's to leave your team with something that keeps working, and the know-how to make it better.

Working with me

I work as a forward deployed engineer for teams around the world, from India. You can start with a two-week sprint to find and prove the best opportunity, go straight to a production build, or keep me on for a few days a month. The services page has the details, and you can see a past project in the Periopman case study.

If any of this sounds like your team, get in touch.