# From solutions engineer to FDE: turning the sales demo into production code

> Once the contract is signed, your demo meets the real world. If the system goes down at 2am, the person who gets out of bed is the FDE, not the SE.

Original: https://fdetimes.net/en/guides/solutions-engineer-to-fde-demo-to-production/

Picture this: the contract has just been signed. The demo you built during the sales round won the customer over, and now they want it to run for real, on real data, for real users. Three months from now, if the system goes down at 2am, who has to get up and fix it?

A comparison of the two roles on Scaler answers bluntly: the FDE, not the solutions engineer (SE). The difference between the two jobs sits almost entirely in that answer.

The SE works within the sales cycle to prove the product *can* work for the customer. The FDE is sent straight into the customer's problem to make sure the product *actually* works in production.

If you are an SE who wants to move into FDE work, most of your skills still apply: understanding customers, talking technical, building fast. What you have to learn is a very different way of thinking. The job is no longer to win the customer's belief, but to carry the consequences when the demo meets the real world.

## The difference between "can" and "does"

Paraform describes the division of labour neatly: the SE sells the vision, the FDE builds it, the customer engineer maintains it. The SE works mainly before the sale, and the FDE picks up exactly where the SE stops. The two roles follow each other on the same customer, but they measure success in completely different ways.

Hapy writes that a demo chatbot can be built in a week. The hard part is making that workflow run reliably inside a real organisation. Kunal Ganglani calls the gap between "the demo works" and "deployed in production at the customer" enormous, and Hapy names the territory in between: the FDE is the one who owns that "messy middle".

One more detail SEs tend to miss: FDEs write production code, but not for the core product. Your code is specific to each customer, such as connectors, pipelines and business logic, running in their environment. So you need enough engineering discipline for it to last, without letting it turn into a fork of the product.

## Taking a demo all the way to production

Take a hypothetical example. You once demoed a chatbot to a retail chain that answers questions about its returns policy. The demo used a CSV file exported by hand from the order system, twenty pre-written questions, and ran on your laptop. The customer said yes, and now you are the FDE on the project.

The first step is not writing code. You sit down and write out everything the demo quietly assumed, then for each assumption note what production requires and who owns it. The table below is part of that list.

| What the demo assumed | What production requires | Who owns it |
|---|---|---|
| The data is a static CSV file | Read directly from the order system, with a sync schedule and alerts when data goes stale | FDE, with the customer's IT team |
| The questions are pre-written | Unfamiliar questions, typos, out-of-scope questions, plus a way to answer "I don't know" | FDE, with the business owner |
| The API always responds | Timeouts, retries, fallback when the service is slow or down | FDE |
| The only user is you | Permissions, audit logs, customer data never leaving their environment | FDE, with the security team |
| Someone sits alongside to fix errors | Runbook, alerts, an on-call engineer when the system fails at 2am | FDE |

The last column is where the career shift shows. In a demo it stays empty, because there is nothing to own. In production, every empty cell is an incident waiting to happen.

Look at the third row as code. The demo version is usually a single line calling the API directly. The production version has to answer a question: when the backend is slow or dead, what does the user see, and what can the on-call engineer read?

```python
import logging, time
import requests

log = logging.getLogger("returns_bot")
MAX_ATTEMPTS = 3

def get_order(order_id: str) -> dict | None:
    # Demo version: return requests.get(f"{API}/orders/{order_id}").json()
    for attempt in range(MAX_ATTEMPTS):
        try:
            r = requests.get(f"{API}/orders/{order_id}", timeout=5)
            r.raise_for_status()
            return r.json()
        except requests.RequestException as e:
            log.warning("order_api_fail order=%s attempt=%d err=%s", order_id, attempt, e)
            if attempt < MAX_ATTEMPTS - 1:  # don't wait again after the last attempt
                time.sleep(2 ** attempt)
    log.error("order_api_down order=%s", order_id)
    return None  # The layer above replies: "The order system is busy, please try again later"
```

There is nothing clever about this code. The difference is in the mindset: every log line is written for someone who will read it in the middle of the night, and that person may well be you.

## Handover is where assumptions hide

The assumptions table above is easy to write when you built the demo yourself. But if you are an FDE taking over a project from another SE, many assumptions will not be in any slide or repo. They live in the memory of the person who gave the demo, and a smooth handover is often a sign they have not been said out loud.

A practical tip: don't let the SE walk you through the demo again, because they will repeat the prettiest path. Ask questions that force them to describe what happened behind the scenes. Which data was cleaned by hand before the demo? Which customer questions did the demo get wrong? Was anything promised verbally that isn't in the contract?

A hesitant answer, or something like "that should just work", is the next row in your assumptions table. Writing these down during the handover is far cheaper than discovering them in the first incident.

## Steps to apply to your own project

Start with an assumptions list like the table above, written in the first week after the contract is signed and reviewed with the customer. Next, run the demo on a sample of the customer's real data and questions, and record where it breaks before you promise any dates. That list of breakages is your first backlog.

Then write the runbook before go-live, not after the first incident. A runbook answers three questions: which alert notifies whom, what to check first, and how to switch the feature off without breaking everything else. If you can't write the runbook, the system isn't ready.

The final step is the one most often forgotten. Hapy treats bringing patterns back to the product team, so that one-off work for one customer becomes a reusable capability, as a core FDE responsibility. Whenever you write the same connector a second time for a second customer, open a ticket for the product team.

## Mistakes SEs make in their first year

The first is the demo instinct: hiding the hard corners so the presentation runs smoothly. As an FDE, the hard corners have to come out as early as possible, because hiding them only pushes the incident to a more expensive moment. You will find yourself telling customers "this doesn't work yet" far more often than you did as an SE.

The second is patching the core product directly to save time, or the opposite, writing sloppy customer code because it is "just integration". Customer-specific code is still production code, and still needs tests, logging and review. Only the scope differs, not the quality.

The third goes deeper and is about you. Paraform warns that an outstanding demo SE may have no desire at all to write production code for six months straight. Demo skills don't prove you have an appetite for that work, so try it before you apply.

## Proving this skill when job hunting

Palantir's Forward Deployed Software Engineer listing describes the work as working directly with customers to quickly understand their biggest problems, then designing and implementing solutions. It also emphasises working in small teams with little supervision and owning high-stakes projects end to end.

When you read FDE job listings, look for words like "own", "end-to-end" and "implement": they signal that the company needs someone to carry production, not just someone to present. On your CV, don't just write "built demos that helped close deals".

Write about a system you were still responsible for after handover: what data it ran on, which incidents you handled, which patterns you brought back to the product team.

In interviews, ask who gets called when the customer's system fails. The answer will tell you whether the role is a real FDE position or an SE job with a new title.

**Key point:** A demo answers "can it work?"; production answers "who gets up when it breaks?"

## Exercise: put your latest demo on the operating table

Take the most recent demo you presented and build an assumptions table like the one above, with at least ten rows and no empty cells in the "who owns it" column. Then pick the hardest cell and write the code or runbook for it. If you finish and find it more engaging than building the demo, you have your answer to the career-switch question.

**Try this week:**

- Take the most recent demo you presented, write down at least ten of its hidden assumptions, and for each one note what production requires.
- Pick one API call in the demo, rewrite it with a timeout, retries, fallback and logging, then deliberately break the backend service to see how the system responds.
- Read an FDE job listing, underline the phrases about ownership, then rewrite one line of your CV to show you were responsible for a system after handover.

## Sources

- [Forward Deployed Engineer vs Solutions Engineer: What's the Difference?](https://www.scaler.com/topics/forward-deployed-engineer-vs-solution-engineer/)

- [Forward-Deployed Engineer vs. Solutions Engineer vs. Customer Engineer: What Startups Actually Need in April 2026](https://www.paraform.com/insights/forward-deployed-engineer-vs-solutions-engineer-vs-customer-engineer)

- [Forward Deployed Software Engineer](https://jobs.lever.co/palantir/bf718bd3-b2ef-451e-8033-cb4d2d9c094b)

- [How Forward Deployed Engineers Turn AI Demos Into Production](https://hapy.co/journal/what-is-a-forward-deployed-engineer-the-ai-role-turning-demos-into-production-systems/)

- [Forward Deployed Engineer: The Hottest Role in AI-First Tech and Why It Pays So Well [2026]](https://www.kunalganglani.com/blog/forward-deployed-engineer-role)