What is a forward deployed engineer? A first-hand answer

A forward deployed engineer is a software engineer who works where the problem is, not where the backlog is. I sit with the people who have the problem, work out what would actually fix it, build that, deploy it, and stay until it is doing its job in production. The title says engineer and means it: the output is working software, not a slide deck or a requirements document handed to somebody else.

"Forward Deployed Engineer" is the title on my home page, my About page and the tab of this site, and until now no page here explained it. This one does, from the inside: what the work looks like week to week, how the role differs from the jobs it gets confused with, the skills it takes, and what to ask before you hire one.

TL;DR

1. A forward deployed engineer (FDE) owns a customer's problem end to end: hearing it, scoping it, building the software and shipping it.
2. Compared with a software engineer, the difference is where the requirements come from: an FDE gathers them first-hand instead of receiving them.
3. Compared with a solutions engineer, the difference is what happens after yes: an FDE builds the solution rather than demonstrating one.
4. Compared with a consultant, the difference is what is left behind: working, deployed software and the specs to change it.
5. Before hiring one, ask to see something they shipped and still maintain, and how they decide what not to build.

Forward deployed engineer meaning: where the title comes from

The title comes from Palantir, which sent engineers to work inside its customers' organizations instead of building from headquarters. AI companies such as OpenAI and Anthropic now hire for the role too, for the same reason: a capable product is worth little until somebody makes it work against one specific customer's messy reality.

Take away the company names and the meaning is simple. Forward is the position: next to the customer, close enough to see the problem rather than read about it. Deployed is the commitment: the work is not done until it runs in production for the people who asked. Engineer is the craft: the person in that position writes, tests and ships the code themselves.

I work as an independent forward deployed engineer. There is no platform behind me that I am deploying; the "product" is whatever software the problem needs, built on a stack I know well — Next.js, TypeScript and Tailwind CSS on the front end, AWS Amplify Gen 2 for auth, data, functions and hosting on serverless AWS — and built with AI coding agents held to engineering standards.

What the work looks like, week to week

When I am in an engagement, the weeks have a recognizable shape, even though no two problems do.

The first week is mostly listening. It starts with a short call about the problem itself — what it costs, who it touches, and what a fix would have to do to count. Then I go and look. The most useful hour in any engagement is the one spent watching somebody do the task the slow way, because the workaround people have built tells you more than any description of it.

Then I write before I code. The problem becomes a small set of GitHub issues, and each issue becomes a written spec: requirements, then a design, then a task list, with an approval gate between each one. That spec is what we agree on. Nothing gets built from a conversation neither of us can go back and read.

The middle weeks are building, in the open. Implementation runs against that task list on a feature branch. I work with Kiro and Claude Code as agentic pair programmers, connected to real tools through MCP, so the agent drives a real browser to check a feature instead of claiming it works. Every change lands on a staging environment first, where the person who asked can click through it and tell me what is wrong while it is still cheap to fix.

The last stretch is release and handover. When staging is right, a deliberate promotion ships it to production. What I hand over is the deployed software, the repository, and the specs — the reasoning behind every decision, so the next person, or the next agent, can change it safely.

Through all of it, a large part of the job is translation in both directions: turning "this report eats somebody’s whole Friday" into requirements an engineer can test, and turning "the auth callback needs a per-branch URL" into a sentence a business owner can make a decision about.

Where the problems come from

The best problems are the unglamorous ones. One project in my portfolio, Perishable Shelf Stacking, came from a job I held: stockers worked perishables from a paper shelf-life list, working out sticker dates and shelf locations by hand. The fix was not clever — a searchable product card with the pre-calculated sticker date and exact shelf locations — but nobody had built it, because no single minute it saved looked important. That is the kind of last-mile problem forward deployed work exists for: it never gets budget, and it quietly costs a team hours every week.

A worked example: the loop I run on every project

The clearest way to show the role is the loop itself, so I published it: how I ship software walks through every step, from a real problem to production.

1. Problem. It starts as a complaint, not a ticket, in the business's own words.
2. Issue. The problem becomes prioritized GitHub issues, small enough to finish, visible before anyone opens an editor.
3. Spec. Kiro turns each issue into requirements, design and tasks, each phase approved before the next.
4. Build. Claude Code works the task list: tests before code, design standards for anything visual, real tools through MCP.
5. Verify. Lint, unit tests and a real browser driving the feature end to end; the staging build is the referee, never my optimism.
6. Production. A promotion pull request moves staging to main, and AWS Amplify ships it.

None of that is exotic, and that is the point. A forward deployed engineer is valuable because they can run the whole loop alone, at the customer's side, without dropping the quality at any step.

Forward deployed engineer vs software engineer

A software engineer and a forward deployed engineer write the same code. The difference is everything around it.

Aspect	Software engineer	Forward deployed engineer
Requirements	Arrive in a ticket, already shaped	Gathered first-hand from the people with the problem
Customer contact	Occasional, often through a product manager	Constant; the customer is the main collaborator
Scope	One part of a larger system	The whole problem, end to end
Done means	Merged and passing review	Deployed and solving the problem

On a product team, a software engineer is protected from ambiguity on purpose: product managers, designers and researchers shape the work so engineers can focus. A forward deployed engineer is that shaping. If the requirement is wrong, it is my requirement, and I find out in front of the customer. That makes the role a poor fit for people who want deep, uninterrupted focus on one system for months, and a very good fit for people who like seeing their code used the week it ships.

Forward deployed engineer vs solutions engineer

This is the comparison people most often get wrong, because both roles sit next to the customer.

A solutions engineer (often called a sales engineer) works before the sale. They understand the customer's needs, demonstrate how an existing product meets them, answer technical objections and design how it would fit. Their success is measured in deals that close and integrations that go smoothly.

A forward deployed engineer works after the yes. The question is no longer "can this work for you?" but "make it work for us" — and the answer is code that did not exist the day before. A solutions engineer shows you a product; a forward deployed engineer builds you a solution and is still there when it meets real data.

The skills overlap — both need to talk to non-engineers, both need to understand a business quickly — but the deliverable is different, and so is the accountability.

Forward deployed engineer vs consultant

A consultant and a forward deployed engineer both arrive from outside, learn a business fast and leave. The difference is what is left behind.

A consultant's deliverable is usually advice: an assessment, a recommendation, a roadmap. Somebody else then has to build it, and the gap between the recommendation and the working system is where most of the value — and most of the risk — lives.

A forward deployed engineer closes that gap personally. What stays behind is deployed software, the repository, and the specs that explain why it was built that way. That last part matters to me: you should be able to change what I built without calling me. If an engagement leaves you dependent on me to touch your own code, I did it wrong.

Forward deployed engineer skills

The skills split into three groups, and the role needs all three at once.

Engineering breadth. You own the whole stack because nobody else is there to take the other half. For me that means front end (React, Next.js, TypeScript, Tailwind CSS), backend and cloud (AWS Amplify Gen 2: Cognito auth, data, serverless functions, hosting), deployment, and testing, including end-to-end tests in a real browser.

Problem framing. Most of the value is decided before the first commit. That takes listening for the problem behind the request, writing requirements somebody can disagree with, and scoping to something that can actually be finished — weeks, not an open-ended engagement. The hardest and most valuable skill is knowing what not to build.

Disciplined speed with AI. AI coding agents make one person able to do the work of a small team, which is a large part of why this role works for an independent engineer. But speed without discipline just produces mistakes faster. Spec-driven development — requirements, design and tasks agreed before code — tests before implementation, code review, and a staging environment that has to agree before anything is called done are what make AI-assisted work dependable instead of merely fast.

Underneath all three is plain communication: explaining a technical trade-off in a sentence a business owner can decide on, and saying "this is not worth building" when it is true.

What to ask before hiring a forward deployed engineer

If you are a founder or a manager deciding whether to bring one in, these questions separate the role from its imitations:

1. "Show me something you shipped that people still use." Not a demo, not a prototype: deployed software with real users. Ask who maintains it now.
2. "What do I get at the end besides the software?" The answer should include the repository and the reasoning — specs, decisions, tests — so your team can change it.
3. "How do you decide what not to build?" Somebody who never says no will build you everything, slowly.
4. "How will I see progress before it is finished?" Look for a staging environment you can click through, not status reports.
5. "How do you use AI, and what stops it from shipping mistakes?" The right answer names the checks — tests, review, staging — not the tools.
6. "What would make you tell me this is not a fit?" A good forward deployed engineer turns down work that is too large to finish or too small to matter.

If you have a problem like this

The work I do best starts as a complaint, not a ticket: the internal tool, the spreadsheet hand-off or the manual report that never gets budget and quietly costs your team every week. If you have one, tell me about it. If I can help, I will tell you how I would approach it. If I cannot, I will tell you that too.