# At Ema, whoever builds the demo has to run it in production

> The Forward Deployed Builder designs, sells and ships the same agentic workflow, so every shortcut in the demo becomes a debt they repay.

Original: https://fdetimes.net/en/guides/ema-forward-deployed-builder-demo-to-production/

You have just demoed an agent that handles IT access requests for new hires. The room nods and the customer agrees to sign. On Monday morning you are the one who has to turn that demo into a system real users depend on. By then, every shortcut you took in the demo comes back to collect.

At Ema, this is the daily work of a Forward Deployed Builder. The company's official job posting describes someone who works inside customers and partners, and says plainly that this is not a support role sitting behind the account team.

One person combines three roles, account lead, solutions architect and builder, working on-site in rotating stints across EMEA and North America.

So the core skill is not a polished demo. You have to build the demo as version zero of production, because the person who lives with the consequences of every demo decision is you. The skill applies to any FDE, even at companies that separate the people who sell from the people who deploy.

## Four jobs, one person

Ema's posting on Accel's job board breaks the work into four steps. First, you take a real business process that is a mess and redesign it as a clean agentic flow on the Ema platform. Then you build a working demo yourself, proof of value so clear the customer has nothing left to object to.

The third step is closing the deal. According to the posting, the builder is the one who removes the customer's reasons to doubt the solution, and that is how the contract is won. The last step is turning the signed contract into a production agentic workflow that the customer trusts and actually adopts.

The product explains why all four steps sit with one person. Ema describes its product as agentic systems that plan and execute enterprise workflows across HR, IT and finance, with more than 250 app integrations. Anyone can draw a workflow touching five systems on a slide. Making it actually run is much harder.

## Design starts with discovery

Picture a mid-sized customer. Each time someone joins, HR emails the manager, the manager replies "ok", IT creates accounts by hand across several systems, and nobody knows where a request is stuck. This is exactly the kind of messy process the posting has in mind.

To redesign it, you need discovery before you write a line of code. Ema's separate Forward Deployment Engineering team describes its discovery workshops as covering four things: how people work today, where it hurts, where the data flows and which integrations are needed.

Do not skip any of the four. Then add one more question, which usually opens up the most: "When did this process last break?"

The output of that session should be a short specification, specific enough to build from straight away:

```yaml
flow: new-hire-access
trigger: HR creates an employee record in the HR system
steps:
  - read_record: get department, job title, start date
  - propose_access: agent proposes an access list based on job title
  - request_approval: send to direct manager, wait for response
  - create_accounts: call the API of each target system
  - report: send a summary to HR and the new hire
exceptions:
  - manager_no_reply_48h: send a reminder, then escalate to their manager
  - job_title_has_no_template: stop, ask IT, add an access template for the new title
  - api_error: retry, then open a ticket for a human to handle
```

The `exceptions` section is where the value lies. Customers can picture the happy path on their own. What they need to see is how the agent copes when things go wrong.

## Which demo wins the technical argument?

Picture the closing meeting, with the customer's head of IT asking the hard questions: "What if the manager is on leave?", "Will the agent grant itself admin rights?". A demo with only the happy path loses on exactly those questions. A demo that runs the `manager_no_reply_48h` branch in front of them has the answer ready.

**Key point:** The demo that wins the contract shows the customer what happens when things break, not only when they work.

This is also why Ema sets its technical bar where it does: enough ability to write some code and use an agentic platform to build a real demo, not just talk about one. The bar does not require you to be an infrastructure engineer. It requires you not to fake anything you cannot later deliver.

| Aspect | Throwaway demo | Version-zero demo |
|---|---|---|
| Data | Sample records typed by hand | One real, anonymised record from the customer's HR system |
| Integrations | Mock screens that look like API calls | At least one real target system called, the rest clearly labelled as simulated |
| Exceptions | None | At least one branch run in front of the customer |
| After signing | Rewritten from scratch | Extended from the same specification that was demoed |

The right-hand column costs a few extra days. In return, when you stay on to deploy, everything promised in the meeting room already has code behind it.

## From design to SLOs

After signing, do not leave the specification sitting in the demo folder. Ema's FDE team writes and maintains a design doc for each "AI Employee", guiding deployment from design through to SLOs. It is a habit worth copying: the document does not stop at a diagram, it ends with numbers the customer can check.

For the access flow above, a minimal design doc might look like this. The thresholds are illustrative only; you agree the real numbers with the customer before go-live.

```yaml
ai_employee: new-hire-access
scope:
  included: HR system (read-only), email, 2 target systems with APIs
  not_included: finance system (phase 2)
agent_permissions:
  - only creates accounts with standard access per the job-title template
  - admin access always requires IT approval, the agent never grants it itself
exceptions: keep the 3 branches from the demoed specification
slo:
  auto_completed: ">= 80% of requests completed without human intervention"
  turnaround: "95% of new hires have all accounts within 1 working day"
  adoption: ">= 90% of access requests go through the flow instead of email"
measurement:
  source: flow logs, reconciled against the IT inbox weekly
  review: 4 weeks after go-live
```

Note the admin-access line: a hard question from the closing meeting has become a written constraint. Each SLO also has all three parts: a threshold, where it is measured and when it is reviewed.

The key word in Ema's description of the final step is "adopts": the customer actually uses it. A workflow that runs while HR goes back to sending emails is not yet production. That is why the `adoption` line sits in the SLOs alongside the technical metrics.

## Traps you set for yourself

The easiest mistake is promising, while closing the deal, things the demo has not proved. When one person both sells and deploys, every "yes, we can do that" is a ticket you will have to work yourself. The safe rule: promise only what has run, and put the rest in the scope of a later phase.

The second mistake is leaving end users out of discovery. You talk to the buyer, but the people who have to change their habits are HR staff and managers. If they are not in the workshop, the "customer trusts and adopts it" part is hard from day one.

The third mistake is building mock integrations without labelling them as mocks. The customer cannot tell what is real, and only on go-live day do you discover that the target system's API needs an access approval process that takes weeks.

## How to show this skill on a CV

When reading FDE job postings anywhere, look for phrases such as "embed", "on-site", "not a support role", or descriptions that run all the way from demo to production.

They tell you the role needs someone who handles the whole chain, not a pre-sales engineer. Ema's posting also sets no fixed number of years of experience, so what you bring as proof is the work you have shipped.

On your CV, do not write "built AI demos". Describe one project through the four steps: what the messy process was at the start, which exception branch the demo ran, who agreed on the strength of that demo, and what the SLOs reached once it was live.

If you apply for a role like this, have a story ready about the gap between demo and production: a time you had to pay off the debt of a demo you built yourself, and how you fixed it.

Ema demands a real demo rather than talk about a demo, and demands that the person who built it stays until the customer trusts it. In a role like that, a good demo is only the first half; the second half is that it still runs after the contract is signed.

**Try this week:**

- Pick a messy internal process at your company (access requests, expense approvals, ticket handling) and write a flow specification covering the steps, the integrated systems and at least two exception branches.
- Build a demo of exactly one exception branch from that specification, running on real or near-real data, then record your screen to add it to your portfolio.
- Write a one-page design doc for the flow with two SLOs, each with a threshold, where it is measured and when, for example the share of requests completed without human intervention.

## Sources

- [Forward Deployed Builder | Careers at Ema](https://www.ema.ai/careers/jobs/b6114740-f6a9-4d98-8d2c-6c6017ba9417)

- [Forward Deployed Builder (Accel jobs board, Ema)](https://jobs.accel.com/companies/ema-unlimited/jobs/89108512-forward-deployed-builder)

- [Engineering Lead- Forward Deployed Engineering (Ema)](https://legaltechroles.com/jobs/engineering-lead-forward-deployed-engineering-ema)

- [Ema Raises $77 Mn To Scale Its Universal AI Employee Platform Globally](https://inc42.com/buzz/ema-raises-77-mn-to-scale-its-universal-ai-employee-platform-globally/)