Forward Deployed Engineer: Role, Skills and Roadmap

It often stops working the way it did in the demo. The customer's documents are messier, their systems are older, and their security team blocks things the demo quietly assumed.

Someone has to close that gap, inside the customer's systems, with real code. That someone is a forward deployed engineer. If you keep seeing the title in job posts and wonder what the work is, this guide answers it.

Picture a common setup. A startup sells a product that reads insurance claim documents with a large language model, the kind of AI that reads and writes text, and fills in the claims system. It has just signed a mid-sized insurer whose claims team receives about 9,000 claim documents a month. The setup is made up, but the problem is real.

In the demo, the product read clean, typed PDFs. At the insurer, many hospital bills are handwritten scans. The claims database is fifteen years old and has no API, meaning no ready-made way for other programs to ask it for data.

Every new connection also needs a request to the firewall team, who guard the network's gate. Sales has done its job. Now an engineer has to make the product work here, and that is the job this guide follows.

A forward deployed engineer is a software engineer placed with a customer to make the company's product solve that customer's real problem, in production. Production means the live system that real staff use every day, not a demo.

Aced (formerly Exponent), an interview-prep company, describes the FDE as an engineer who works directly inside a customer's team to scope, build and deploy production software. Its guide places the FDE after the contract is signed. It also dates the role to around 2009, long before the current AI hiring wave.

Three words come up in every FDE job post. Here is what each one means at the insurer.

• Integration: connecting two systems so that data flows between them. The claims product must read new claims from the insurer's old database.
• Customer environment: the customer's own servers, cloud account, network and security rules. At the insurer, the servers are reachable only through its VPN, a private encrypted connection into its network.
• Scoping: agreeing exactly what will be built, by when, and how everyone will know it works. A first scope might be one product line in one city, with a person checking every result.

Companies hire FDEs because many products, AI products especially, need real work before they fit a customer. Each customer's data is messy in its own way. Their documents, old systems, approval rules and security reviews all differ.

An FDE is not a salesperson or a support agent. A sales engineer helps win the deal with demos and usually does not own production code. A support engineer answers tickets. An FDE is judged on whether the deployment works and keeps working.

An AI solutions architect designs how a business problem becomes an AI system, while a forward deployed engineer builds and runs that system inside one customer's environment. One mostly makes and explains design decisions. The other mostly writes and owns production code.

The two jobs overlap, and small companies often blur them. Aced's comparison puts solutions architects and sales engineers before the sale and the FDE after it. Solutions architects there build proofs of concept, quick builds that show an idea can work, while the FDE owns production code at the customer.

Think of a film shoot. The scriptwriter plans each scene on the page, in the office. The location manager works where the scene is shot, when the rain arrives early and the street permit has not come through.

Map it part by part. The script is the architect's design. The location is the customer environment. The rain and the missing permit are messy data and slow security reviews. The location manager is the FDE, who still gets the scene shot.

Where the picture breaks: a location manager rarely changes the script for the next film. An FDE does, by sending repeated fixes back to the product team so the product itself improves.

Day to day, an FDE finds the customer's real problem, builds and connects software, checks it on real data, and keeps it running. The mix changes with each phase of a deployment, so no two weeks look the same.

Here is one realistic week at the insurer, early in the deployment. The claims team wants the product to read its 9,000 monthly documents and fill in the claims system.

1. 1

   Monday: find the real problem

   Sit with three claims handlers for half a day. Learn that the worst delay is not reading forms but chasing missing hospital bills. The written requirement never mentioned this.

2. 2

   Tuesday: connect the systems

   Write a connector, a small program that pulls new claims from the old database every ten minutes. Lose four hours waiting for the firewall team to let the traffic through.

3. 3

   Wednesday: test on real data

   Run the product on 200 past claims that staff had already checked by hand. Hospital names come out badly, because many bills are handwritten.

4. 4

   Thursday: fix and ship

   Add a review queue, so fields the product is unsure about go to a person. Release it to five claims handlers, not all forty.

5. 5

   Friday: report back

   Write a short note to the product team. Other insurers will hit the same missing-bill problem, so the review queue should become a standard feature.

What just happened? The most useful finding of the week came on Monday, from watching people work, before any code. The code that shipped on Thursday was small, but it went to real users.

The diagram shows the loop behind that week. Follow it from the top and notice the last arrow: what an FDE learns at one customer flows back into the product.

Around that loop sits work that rarely appears in a job post:

• Getting access: accounts, VPN and single sign-on (one company login used for many apps), plus approval to see real data.
• Passing security reviews, where the customer's team checks how the product stores and sends their data.
• Writing runbooks, short documents that tell the customer's staff what to do when something breaks, and training staff to use them.
• Joining incident calls when the deployment breaks at night or during a month-end rush.

An FDE needs three groups of skills: everyday engineering, enough applied AI to make a model behave on real data, and customer skills to agree on the real problem. Most good FDEs are solid at all three, not perfect at one.

Engineering skills

This is the base, and interviews test it first. You will spend more time reading other people's systems than writing fresh ones. Aced's guide lists production Python plus one of TypeScript, Go or Java.

• Python for scripts, data clean-up and small services, plus enough of one web language to fix a simple front end.
• SQL, the query language of relational databases, because many customers keep core records in older databases.
• APIs and logins: calling other systems safely, handling tokens, retries (trying again after a failure) and rate limits (caps on how many requests you may send).
• Cloud and network basics: VPNs, firewalls, containers (packaged apps that run the same everywhere), and why a request times out.
• Debugging from logs in a system you did not build, often with less access than you want.

AI application skills

You rarely build models from scratch. You make a product's AI work on this customer's data, and you prove that it works. That needs four skills: retrieval, evaluation, output checks and cost control.

Retrieval means fetching the customer's own documents and giving them to the model along with the question. An eval, short for evaluation set, is a fixed list of real examples with known answers that you run after every change.

Output checks are rules in code that catch a bad answer before anyone sees it. Cost control matters more than beginners expect. If your model provider bills per token, a small piece of text, cost grows with every page you send.

A design that feels cheap for one team of five can become painful when forty teams use it all day. So measure cost per document on the eval, not just accuracy.

Customer skills

• Discovery: asking what goes wrong today, watching people work, and finding the problem behind the request.
• Writing: short scoping notes, status updates and runbooks that busy people actually read.
• Saying no, or not yet: protecting the scope when every meeting adds a new wish.
• Explaining trade-offs to non-engineers, such as why 100 percent accuracy is not a realistic promise for an AI system.

None of this is new to software engineering. SWEBOK, the IEEE Computer Society's map of the field's core knowledge, lists software requirements as a knowledge area. Its 2024 version 4 added three more: architecture, operations and security.

Build production basics first, then messy integration skills, then AI on real data, then customer practice, and finish with one real deployment for a real user. Each stage ends with something you can show in an interview.

How long it takes depends on where you start. As a rough planning guess, not a measured figure, someone who already ships web apps might need about six months at eight hours a week. A complete beginner should expect longer.

Each stage leans on the one before it, as the diagram shows. Do not jump to AI before you can deploy and debug a plain service.

1. 1

   Stage 1: production basics

   Build one small service with a database, a login and logs, and deploy it to a cloud account. Show a running app, with an alert that fires when it fails.

2. 2

   Stage 2: messy integration

   Connect two systems never designed to talk. Use a CSV export (a plain-text table file), a slow API with rate limits, and a webhook (an automatic message one system sends when something happens). Show a connector that retries safely and never imports a row twice.

3. 3

   Stage 3: AI on real data

   Add retrieval or document reading to a real public dataset, then build an eval of 50 cases with known answers. Show accuracy, cost per case and the ten worst failures.

4. 4

   Stage 4: customer practice

   Interview two people about a task they dislike at work. Write a one-page scoping note and get them to agree to it. Show the note, and what changed after you listened.

5. 5

   Stage 5: one real deployment

   Ship something small for a real user, such as a local clinic, a non-profit group or a relative's business. Support it for a month. Show its usage, one incident and how you fixed it.

An FDE interview usually has several rounds that test coding, problem breakdown, integration design and how you handle customers. The number and order of rounds vary a lot by company, so ask the recruiter for the list early.

• Recruiter screen: why this role, and how you feel about travel and customer work.
• Practical coding: often parsing a messy file, cleaning data or calling an API. Some companies still ask data structures and algorithms questions.
• Problem breakdown: a vague customer problem that you split into parts, questions and a first plan.
• Integration or system design: how the product connects to the customer's systems, and what happens when a part fails.
• Customer role-play: an interviewer plays an unhappy or demanding customer.
• Behavioural round: past projects, ownership and how you work under pressure.

Here is a sample problem breakdown question. A bank's loan team says approving small business loans takes three weeks and wants AI to make it faster. What do you do?

1. 1

   Ask about the goal

   Ask what faster means and for whom. Is the target three days or three hours? Ask what a wrong approval costs, because that decides how much a person must review.

2. 2

   Map today's process

   Ask for each step and how long it takes. Often much of the delay is waiting for documents or approvals, not reading them.

3. 3

   Separate AI from plain fixes

   Say which steps need a model, such as reading bank statements. Say which need only a checklist or a reminder message.

4. 4

   Propose a thin first version

   Pick one step, one branch and a small group of users. Name the data access you need and the security review you expect.

5. 5

   Say how you will measure it

   Agree an eval of past loan files with known outcomes, plus a target and a date. Name the biggest risk, such as wrong extractions, and how you will catch it early.

The customer role-play is where many strong coders lose points. Common traps are agreeing to every request, blaming the customer's systems, and promising dates you cannot control.

Calm, specific answers work better: what you will do today, what you need from them, and when you will update them. For the wider AI engineer interview loop, see our guide on AI engineer interview prep.

Common next steps are lead FDE, solutions architect, product manager, core product engineer, engineering manager or founder. The role gives you rare evidence, because you have seen many customers' real problems up close.

The main pros are fast learning, visible impact and wide career options. The main cons are travel, constant context switching and custom work that can feel throwaway. Whether it fits you depends on how you handle people and pressure.

The good parts:

• You learn fast, because every customer breaks your assumptions in a new way.
• Your impact is visible: you watch real staff use what you built.
• You build range across code, data, AI, security reviews and people skills.

The hard parts:

• Travel can be heavy. Aced's guide, citing an outside analysis of 1,000 FDE job posts, says most roles expect 25 to 50 percent travel for on-site customer work (as of 2026).
• You switch context often, between customers, tools and urgent calls.
• Much of your code is custom and may be thrown away once the product catches up.
• You answer to two sides: your company's plans and the customer's demands.

A quick self-check: if most of these lines sound like you, the FDE path is worth a serious look.

• You would rather fix a broken system today than design a perfect one next month.
• You enjoy talking to non-engineers and do not mind being put on the spot.
• You can debug a system you did not build, with half the access you want.

Going live means releasing to real users. You run the system on an eval of known cases and release only when accuracy and average cost both meet a bar agreed with the customer. A go-live check is a short script that does exactly that and lists the failures to read.

The script below runs as it is on Python 3.13. The fake_system function is a made-up stand-in for the real pipeline. It returns a short code for the hospital on the bill, such as clinic_a, and a cost in rupees. It misreads one handwritten bill on purpose.

from collections import namedtuple

Case = namedtuple("Case", "id input expected")
Result = namedtuple("Result", "output cost_rs")


def go_live_check(cases, run_system, min_accuracy=0.9, max_cost_rs=2.0):
    if not cases:
        raise ValueError("no cases to check")
    correct, total_cost, failures = 0, 0.0, []
    for case in cases:
        result = run_system(case.input)
        total_cost += result.cost_rs
        if result.output == case.expected:
            correct += 1
        else:
            failures.append(case.id)
    accuracy = correct / len(cases)
    avg_cost = total_cost / len(cases)
    ok = accuracy >= min_accuracy and avg_cost <= max_cost_rs
    return ok, accuracy, avg_cost, failures[:10]


# A stand-in for the real pipeline: it misreads one handwritten bill.
def fake_system(document):
    hospital = "hospital_b" if document == "bill-07" else "clinic_a"
    return Result(output=hospital, cost_rs=1.5)


cases = [Case(f"c{i}", f"bill-{i:02d}", "clinic_a") for i in range(1, 11)]
print(go_live_check(cases, fake_system))

Save it as go_live.py and run python3 go_live.py. You should see (True, 0.9, 1.5, ['c7']): it passes, 90 percent accuracy, 1.5 rupees per document on average, and one failure to read.

Pause and predict: if each document cost 2.5 rupees instead, would the release still pass? Change cost_rs=1.5 to cost_rs=2.5 and run it again. You should see (False, 0.9, 2.5, ['c7']). Accuracy did not change, but the release fails on cost alone.

Two limits to know. Exact matching with == suits fields like a policy number or a date. Free-text fields need a looser comparison, such as ignoring case and extra spaces, or a person reviewing them.

Also, failures[:10] keeps the first ten failures in eval order, not the ten worst. Those are the cases you read with the customer, one by one.

You make every write idempotent, meaning running it twice has the same effect as running it once. The usual way is to key each row on a stable ID from the source system. Then write with an upsert, an insert that updates the row if it already exists.

This matters because connectors retry. At the insurer, a poll can time out after the rows arrived but before the connector saved its progress. The next poll then fetches the same rows again. Without a stable key, every retry adds duplicate claims.

The script below uses SQLite through Python's built-in sqlite3 module. The amounts are in rupees, so 120000 is 1.2 lakh (120,000) rupees.

import sqlite3

db = sqlite3.connect(":memory:")
db.execute(
    "CREATE TABLE claims (claim_id TEXT PRIMARY KEY, amount_rs INTEGER, status TEXT)"
)


def import_batch(rows):
    db.executemany(
        "INSERT INTO claims (claim_id, amount_rs, status) VALUES (?, ?, ?) "
        "ON CONFLICT(claim_id) DO UPDATE SET "
        "amount_rs = excluded.amount_rs, status = excluded.status",
        rows,
    )
    db.commit()


batch = [("CLM-1001", 45000, "new"), ("CLM-1002", 120000, "new")]
import_batch(batch)
import_batch(batch)  # a retry after a timeout sends the same rows again
import_batch([("CLM-1002", 120000, "approved")])  # a later change
print(db.execute("SELECT * FROM claims ORDER BY claim_id").fetchall())
print(db.execute("SELECT COUNT(*) FROM claims").fetchone()[0])

Run it and you should see two lines. The first is [('CLM-1001', 45000, 'new'), ('CLM-1002', 120000, 'approved')]. The second is 2, so the retried batch added no rows.

What just happened? The second import_batch hit the primary key, the column that must be unique, on both rows and updated them in place. The third call changed CLM-1002 to approved, because excluded means the row the insert tried to write.

The ON CONFLICT upsert syntax needs SQLite 3.24.0 or later, from June 2018. To see your version, run python3 -c "import sqlite3; print(sqlite3.sqlite_version)". We ran this script on 3.45.1.

You must know who controls the data, what the contract lets you do with it, and which AI-specific risks the customer's security team will ask about. In India, the first question is answered by the Digital Personal Data Protection Act, 2023.

The Act calls the organisation that decides why and how personal data is processed a Data Fiduciary. A Data Processor handles that data on its behalf. In many deployments the customer is the fiduciary and your company acts as its processor.

The contract decides the details, so ask before you copy any data anywhere. The government notified the DPDP Rules, which put the Act into practice, in November 2025. Most duties start after an eighteen-month phased compliance period, though a few rules start earlier.

In January 2026 the IT ministry proposed cutting that period to twelve months. A law firm tracker found no amendment notified as at September 2026. As of 19 October 2026, check the current deadlines with your legal team.

AI deployments add risks of their own. OWASP, a non-profit that publishes security guidance, keeps a top 10 list for LLM applications, meaning apps built on large language models.

Its 2025 list includes prompt injection, sensitive information disclosure, excessive agency and unbounded consumption. In plain words: documents can hide text that steers the model, private data can leak into answers, the AI can get too much power, and costs can run away.

Real customer documents and real users test all four quickly. At the insurer, a scanned bill could carry hidden instructions, so the review queue and output checks are security controls too.

Customers in banking or insurance may also ask how you manage AI risk. A common reference is the AI Risk Management Framework from NIST, the US standards agency. It is a voluntary guide released in January 2023. Its core has four functions: govern, map, measure and manage.

NIST added a profile for generative AI in July 2024. As of 19 October 2026, its page says AI RMF 1.0 is being revised, so cite the version you used.

Walk the panel from the customer's goal to a safe rollout, naming the access, failure handling and checks a real deployment needs. Use the insurer as your example: 9,000 documents a month is about 300 a day, so load is not the hard part.

1. 1

   Pin down the goal and the bar

   Say who uses the result and what a wrong field costs. Agree the accuracy and cost bar for the go-live check.

2. 2

   Map the systems and the access

   Name the old database, the VPN and the firewall request. Ask for read-only access or a regular export, and say who approves it.

3. 3

   Design the connector

   Poll every ten minutes for claims changed since the last run, using a last-updated column if the old database has one. Key each row on the claim ID and upsert, so retries never create duplicates.

4. 4

   Add the AI step with a safety net

   Send unsure fields to a review queue. Run the eval before every release, and treat document text as untrusted input.

5. 5

   Plan failure and rollout

   Say what happens when the database is down: wait, retry with growing gaps, and alert a person. Release to five users first, with logs and a weekly review.

6. 6

   Close the loop

   Say which fixes you would report to the product team, so the next customer starts further ahead.