A founder I know spent $40,000 on an embedded engineer to "get the company into AI." Six weeks in, the engineer had built a beautiful prototype that read data from... nothing. Because there was no data. There were 11 years of invoices in a shared drive folder called FINAL_v2_REAL, a CRM nobody had updated since the previous ops manager left, and an inventory spreadsheet with nine different ways to spell the same SKU.
The engineer was good. The engagement was doomed. It's the textbook case of when not to hire a forward deployed engineer, and nobody says it out loud before signing.
This post is the cold shower: an honest look at the scenarios where an FDE is the wrong tool, from someone who would happily take your money in almost every other one.
Short version, up front. Don't hire an FDE when your data is a landfill, when you actually need a platform team, when you can't name the workflow you're fixing, or when nobody internal will own the result. In each case, an FDE is an expensive band-aid on a problem that needs a different tool: a cleanup sprint, a staffing plan, a decision, or a person on payroll. Spend the money on the diagnosis first, and the FDE conversation gets dramatically cheaper.
The Pitch That Got You Here
The pitch is seductive because it's mostly true. A forward deployed engineer embeds with your team, learns the actual workflow, and ships working software in weeks instead of quarters. For the right problem, it's the fastest money you'll ever spend on software.
"For the right problem" is doing heroic work in that sentence. The same qualities that make an FDE great, like speed, autonomy, and tolerance for chaos, make them terrible value when the chaos isn't the kind software fixes. A great engineer embedded in the wrong situation doesn't produce a great outcome. They produce an expensive lesson.
When Not to Hire a Forward Deployed Engineer
Let's put the list on the table before the stories. You should seriously reconsider hiring an FDE if any of these are true:
- Your data is a landfill. The inputs are scattered, contradictory, or nonexistent.
- You need a platform team. The real ask is infrastructure serving dozens of teams, not one workflow.
- You can't name the workflow. "We want to use AI" is a mood, not a project.
- Nobody internal will own the result. The thing ships and then orbits, unmaintained, forever.
One of these alone is survivable. Two or more, and you're buying a very expensive band-aid.
Your Data Is a Landfill
Say you run a regional distribution company, 60 people, and you want an FDE to build a demand forecasting tool. Sounds great. Then the engineer asks for sales history and gets: three years in the ERP, two years in a different ERP from an acquisition, and one year that lives in a spreadsheet maintained by a guy named Dale who uses "misc" as a product category 400 times.
The engineer now has two options. Spend three months doing data archaeology, which is skilled work but not what you thought you were buying. Or build the tool on garbage inputs, which produces confident, wrong forecasts at impressive speed. Neither is a good use of FDE rates.
What fixes it isn't a better engineer. It's a boring, unglamorous data cleanup sprint. Sometimes that's a few weeks of focused work by someone cheaper, sometimes it's just deciding which system is the truth and migrating to it. Do that first. Then the forecasting tool takes six weeks instead of six months, and it actually works.
You Need a Platform Team, Not a Person
Different failure mode: the work is real, the data is fine, but the shape of the problem is wrong for one embedded engineer. If your ask involves single sign-on for 800 employees, uptime SLAs, compliance audits, or infrastructure that five other teams will build on top of, you don't need an FDE. You need a platform team, or at least a staffing plan. One embedded engineer cannot simultaneously be your SSO migration, your uptime guarantee, and your compliance posture; that is three jobs in a trench coat.
The Scale Sniff Test
Count the stakeholders. An FDE engagement works when there's roughly one team with one painful workflow. If your whiteboard sketch of the project has arrows pointing to four departments, an infrastructure budget line, and the phrase "single source of truth for the whole company," that's a program, not an engagement. Programs need staff, roadmaps, and meetings. So many meetings.
Hiring one engineer into a program-shaped hole doesn't make the hole smaller. It just gives you one very tired engineer.
You Can't Name the Workflow
On every intro call I run a one-sentence test: who does what today, in which system, and how long does it take? "Sarah in ops copies order details from email into the ERP, about 90 minutes a day" is a workflow, and it's automatable. "We feel like we're falling behind on AI" is not.
If you can't answer that sentence, an FDE can't save you, because there's nothing to build yet. There's a discovery problem, and discovery problems need thinking, not coding. Some FDEs will happily do the thinking with you; it's genuinely part of the skills that matter in this role. But you should know that's what you're paying for. Paying senior engineering rates for what is actually a business-decision workshop is a choice. Make it with your eyes open.
What to Do Instead
For each trap, there's a cheaper ladder rung:
- Data landfill: run a scoped cleanup sprint. Pick the one system that's the truth, migrate, delete the rest. Weeks, not quarters.
- Platform-shaped problem: hire, or use staff augmentation for pure capacity once a real tech lead has drawn the map. Heads-down hands are valuable after someone decides what the hands should do.
- No named workflow: do the one-sentence exercise with your team for a week. Write down every task that eats more than five hours a week. The top of that list is your project.
- No internal owner: appoint one before anyone writes code. The owner doesn't need to be technical. They need to care, and to have the authority to say "yes, that's how we do it."
Notice what these have in common: they're all cheaper than an FDE, and they all make a future FDE dramatically more effective. This isn't an argument against the model. It's an argument for sequencing.
The Questions That Save You Money
Before your next call with any embedded engineering shop, write down answers to these five:
- The workflow that hurts, who does it today, and what it costs per week.
- Where the data for it lives, and how clean it really is.
- Who internally owns the result after launch.
- Whether this is one team's problem or a company-wide platform.
- What "this worked" looks like in 90 days, in numbers.
If you can answer three or more confidently, call the FDE. You'll have a fantastic engagement. If you can't, congratulations: you just saved yourself five figures and an awkward post-mortem. The work you do instead will feel boring. Boring is where the money is.
And once the foundation is set, the embedded model stops being a band-aid and starts being the unfair advantage everyone promised you. The FDEs will still be there. We'll even be cheaper, because you'll finally be able to tell us what to build.