You need a forward deployed engineer (FDE) in one of two situations: customers have signed but aren’t getting live, or nobody is close enough to your users to work out what to build. In both, the bottleneck sits between your product and the people using it, and fixing it takes someone who can both talk to users and ship code.
If your problem is a clear backlog and too few hands, you don’t need an FDE. You need more engineers.
New to the term? Start with what a forward deployed engineer is.
Situation 1: customer go-lives are stalling
A go-live is the moment a customer starts using your product for real work, with their own data. Stalled go-lives are expensive because the sale looks finished while the value hasn’t arrived.
Signs you’re here:
- Signed customers wait weeks or months for onboarding, and the delay has nothing to do with their enthusiasm
- The demo works, but the product fails on a customer’s real data
- Each customer has different systems, formats or rules, so the last setup doesn’t help much with the next one
- Your product engineers keep getting pulled off the roadmap to help with a single account
- Your customer success team can see the problem but can’t change the code
This pattern is common in AI products. S&P Global Market Intelligence reported that the share of companies abandoning most of their AI initiatives before production rose from 17% to 42% in a year. Its survey covers organizations already running or testing AI, not startups specifically, so read it as context. Insight Partners calls this an AI value gap and describes the FDE as the person who finishes what the product can’t do alone.
It isn’t only an AI problem. First Round Review reports that Ironclad’s first 50 customers were highly varied, and that Promise needs FDEs because US states run government programs differently. Where customers differ this much, a standard onboarding checklist runs out quickly.
What an FDE changes here
The FDE takes the messy data, builds the connection to the customer’s systems, fixes what breaks, and tells your team what should be built into the product so the next go-live is faster. Your product engineers get their time back.
They can also help before the contract closes. Looker’s co-founder told First Round that the company used this approach during free trials, working with prospects’ real datasets.
You’ll need to choose which customers get this attention. FDE time doesn’t scale well across small accounts. First Round reports that Ironclad sent its engineers only to its highest-value customers and standardized smaller implementations.
Situation 2: nobody is close enough to users
The other situation is less about delivery and more about deciding what to build. Your company has users, or people who might become users, and no one with both the time to understand them and the ability to act on what they learn.
Signs you’re here:
- The founder is the only person who talks to users, and has run out of hours
- You’re a non-technical founder with plenty of user feedback and nobody who can turn it into software
- Engineers ship to tickets, and features go unused
- User requests pile up in a channel or spreadsheet and never get addressed
- Feedback passes through several people before it reaches the person writing code
First Round’s interviews describe this well. Jake Stauch of Serval argues that removing go-betweens recreates the fast feedback loop of an early startup, and he points to requests that piled up in a Slack channel at Verkada, which FDEs can clear by solving the need behind them. Shilpa Balaji, a former Palantir FDE, argues that time spent with a customer surfaces needs a short discovery call would miss.
PostHog adds a related case: entering a new market where you don’t yet understand what customers need. It gives Ramp as an example.
If you’re a non-technical founder
You can work with an FDE without being able to review their code. You set priorities and judge what reaches users. The engineer makes the technical calls.
This only works if you can talk to users and make product decisions. An FDE can reduce what you don’t know, but they can’t replace your judgement about which customers and problems matter. If you can’t do that yet, or don’t want to, an FDE won’t fill the gap.
Insist on evidence you can see without reading code: does it work, do users use it, and can the engineer explain the trade-offs in plain language?
When you don’t need one
An FDE is a poor choice in several common cases.
Your growth playbook is already working. PostHog’s advice is that if the standard route to product-market fit is working, you shouldn’t hire one.
Your product is self-serve. James Honsa, who led the equivalent team at Ironclad, told First Round that the role belongs with selling to large customers. If you expect a freemium model with many small accounts, the time per customer won’t pay back.
You have a fixed product vision. Balaji warns that a founder who is prescriptive about the product will likely find an FDE a poor fit, since the role lets customer needs shape the product.
You have a clear backlog and need capacity. A good software engineer can do this work, and will probably enjoy it more. Forward deployed engineer vs staff augmentation explains the difference.
You really want someone to run demos. Tiffany Siu, First Round’s head of talent, warns that if success means closing deals or running demos, the role is closer to sales. See forward deployed engineer vs solutions engineer.
You can’t give them access. An FDE with no route to users or customer systems is just an expensive engineer. Sort this out first.
Match the symptom to the role
| What you’re seeing | What you probably need |
|---|---|
| Go-lives stall on real data and customer-specific systems | FDE |
| Users have needs nobody can work out or ship | FDE |
| Go-lives stall because of checklists, training and project coordination | Implementations lead |
| Customers are live but not getting value from features that already exist | Customer success manager |
| Deals stall because prospects need a technical demo or answers | Solutions engineer |
| A well-specified roadmap is running late | Software engineer or added capacity |
| You don’t yet know who your user is | Founder time with users, before any hire |
The table is a rule of thumb rather than research. Siu’s experience supports the general point: she describes a founder who thought they needed an FDE and ended up hiring an implementations lead.
Three questions before you decide
Siu suggests these before opening a role, and they work for a solo founder as well as a CTO:
- What triggered this, and who does the work today? Also ask what happens if you hire no one. If the answer is “not much”, wait.
- What does this person’s day look like? Write it out. If it’s mostly tickets, it isn’t an FDE role.
- How will you measure success? Choose something you can observe, such as the number of customers live, time to go-live, or whether a shipped feature gets used.
Insight’s panel adds a discipline worth borrowing: define entry criteria, exit criteria and the signal that would make you stop before you begin. Enthusiasm from a customer doesn’t mean they’re ready, and the same goes for your own team.
Once you’ve decided
If one of the two situations fits, the next questions are how to bring someone in and what it costs. How to hire a forward deployed engineer compares a direct hire, a contractor and a monthly placement, and the cost guide compares the full cost of each.
Where epicX fits
epicX places engineers for these two situations, from $5K a month, with a 2-week trial where you can leave and pay nothing. You direct the engineer and own the result, and epicX doesn’t review the work, so it suits a founder or CTO who can set priorities and judge what reaches users. If you recognize one of these situations, talk to a founder about hiring a forward deployed engineer.