FDE vs Solutions Engineer vs Freelance Developer
Forward Deployed Engineer vs Solutions Engineer vs freelance developer — who owns production code, who embeds with operators, and which role you actually need for AI in a real customer stack.
*Same customer. Three different jobs. Pick the delivery model, not the trendiest title.*
People mix up **Forward Deployed Engineer (FDE)**, **Solutions Engineer (SE)**, and **freelance developer** because all three can sit on calls, write some code, and talk about AI. The difference is not vocabulary. It is **what they are paid to own**: a closed deal, a shipped milestone, or a production system operators can run without them. If you need the short role definition first, read the Forward Deployed Engineer hub. For the day-to-day loop, see what a Forward Deployed Engineer actually does.
Quick answer
| Role | You hire them to… | Success looks like… |
|---|---|---|
| Forward Deployed Engineer | Embed and ship production software in the customer's environment | Operators run the system; messy integrations are owned; field lessons feed product or open tools |
| Solutions Engineer | Win and support the technical sale — demos, PoCs, architecture credibility | Deal progresses; PoC accepted; handoff to delivery or CS |
| Freelance developer | Deliver scoped work against a brief or tickets | Milestone accepted; invoice cleared |
**One line:** FDE = engineer first, customer-embedded second. SE = technical sale first. Freelance = scoped delivery first.
Side-by-side comparison
| Dimension | Forward Deployed Engineer | Solutions Engineer | Freelance developer |
|---|---|---|---|
| Primary job | Ship production software in the customer's environment | Win and support the technical sale or PoC | Deliver scoped tickets or projects |
| Writes production code? | Yes — core of the role | Sometimes light; often demos and reference architectures | Yes |
| Embeds with operators? | Deeply — workflows, constraints, day-2 ops | During sales and onboarding | Project-scoped |
| Owns messy integrations? | Yes — SSO, legacy data, security review, half-documented APIs | Advises; rarely owns long-term | Only if the contract says so |
| Feeds product or open tools? | Expected — field to product or OSS | Sometimes — win stories, feature requests | Rarely |
| Typical artifacts | Production paths, runbooks, evals, guardrails, handoff docs | Decks, demos, PoC environments, RFP answers | PRs, tickets, delivered features |
| Time horizon | Engagement until the system is operable | Pre-sale, close, light post-sale | Sprint, fixed scope, or retainer tickets |
| Failure mode | Demo that never hardens; hero dependency on the engineer | PoC that cannot become production | Spec met, business outcome missed |
| Success metric | Working system operators can run | Deal closed or PoC accepted | Milestone accepted |
Same project, three different outcomes
Imagine a company says: *"We need an AI support agent on our help docs."*
Solutions Engineer path
Discovery call, competitive landscape, architecture diagram. A polished demo on sample docs. A PoC that answers happy-path questions. Hand-off note: "Engineering will productionize after signature."
**Win if** the deal closes. **Risk if** nobody owns SSO, escalation, evals, or the mess in the real help center.
Freelance developer path
Scope: "Build a chat widget and RAG over docs." Ships against the written brief. Done when acceptance criteria on the ticket pass.
**Win if** the milestone is fair and complete. **Risk if** the brief never included escalation, citation quality, or operator handoff — and nobody is paid to discover that.
Forward Deployed Engineer path
Scope the real outcome: deflect tier-1, escalate cleanly, attach ticket summaries. Map *their* docs, auth, ticketing tool, and who sits on the queue. Thin vertical slice on **live** help content. Harden: grounding, escalation rules, logging, simple evals. Handoff: a runbook so support leads can operate it.
That is the shape behind work like SupportPilot (docs RAG with human escalation) and DotChat (answers cited to source pages) — not "call an API and ship a widget."
Where the titles blur, and how to unblur them
"Our SE writes a lot of code"
Some Solutions Engineers are deeply technical. The test is still: **are they measured on production ownership in the customer environment, or on pipeline and PoC?** If the answer is pipeline, it is SE — even if they open a PR.
"Our freelancer embeds with us"
Some freelancers work like FDEs: on-site energy, full systems thinking, leftover runbooks. The test is the **contract and incentives**. If scope is tickets and "done" is acceptance of a milestone with no field feedback loop, it is freelance delivery — even if the person is excellent.
"FDE is just a fancy consultant"
Consultants often optimize for recommendations and workshops. FDEs optimize for **running software**. Overlap exists; the artifact differs. Prefer people who leave systems and docs, not only slides.
"In AI startups everyone is a bit of everything"
True early on. Titles still matter when you hire, price, or explain yourself. If you sell FDE and deliver SE demos, trust dies. If you sell freelance tickets and the client expected embedded production ownership, the engagement explodes mid-way.
Which one do you need?
**Hire or engage an FDE when** the idea is stuck in demo mode; the environment is messy (legacy CMS, many tools, compliance, incomplete APIs); you need someone who can talk to founders **and** merge production code; you are embedding agents into support, CMS or Webflow ops, internal tools, or spend workflows; or you want leverage left behind — runbooks, patterns, open tools — rather than a black-box exit.
**Hire a Solutions Engineer when** you are selling a platform and need technical credibility in the sales cycle, PoCs and architecture narratives unblock deals, and delivery after signature is owned by another team.
**Hire a freelance developer when** scope is clear, acceptance criteria are honest, and the environment is already understood; you need capacity on a defined surface; and you do not need embedded discovery or long-lived production ownership from that person.
**Hybrid reality:** many companies need SE **and** FDE. Many founders need a freelancer who can *temporarily* operate in FDE mode — price and scope that explicitly, or you will underpay and over-expect.
How I use these labels for myself
I position as a **Forward Deployed Engineer** for AI agents, RAG, and automation inside real stacks (Webflow, Supabase, n8n, Next.js): scope with the client, ship against their data, harden with guardrails, hand off something that survives without me. That is not the same product as taking tickets indefinitely, and not the same as running an enterprise sales PoC.
Proof lives in case studies and open source — SupportPilot, DotChat, webflow-agent-kit, AgentPayOps — and the role definition lives on the Forward Deployed Engineer page.
If you are hiring for FDE-shaped work: get in touch, or take the CV from the hub page.
Decision checklist you can steal
Before you post a role or sign a contract, answer in writing:
1. What is the **success metric** — deal, milestone, or operable system? 2. Who **owns production** after week four? 3. Is discovery **in scope**, or is the brief already true? 4. Do we need **field feedback** into a product or open toolkit? 5. What does **handoff** look like if this person disappears for two weeks?
If (1) is an operable system, (2) is unclear, (3) is yes and (4) is yes — you are describing an FDE. Write the title and the contract to match.
Is a Forward Deployed Engineer just a Solutions Engineer who codes more?
No. Coding volume is not the divider. Ownership of production outcomes in the customer environment is. Solutions Engineers can code; FDEs are measured on systems that run after the meeting ends.
Can a freelancer work as an FDE?
Yes, if the engagement is scoped that way: embed, real data, harden, handoff, and optionally feedback into tools or product. Call it what it is and price the discovery and production risk — do not hide FDE work under a cheap ticket rate.
Which role is best for AI agent projects?
If the agent must live in a customer's tools, data and ops, you need FDE-shaped delivery whatever the badge says. If you are selling a platform and need a credible proof of concept in the sales cycle, you need a Solutions Engineer. If the architecture is already decided and you need hands, freelance capacity can be enough.
Where should I start if I am still confused?
Read the Forward Deployed Engineer hub, then the field guide, what a Forward Deployed Engineer actually does.
I ship production AI for startups and teams — agents, RAG, automations — on a decade of design & Webflow craft.
About me →Keep going.
How I price a Forward Deployed Engineer engagement
How I scope and price FDE-style AI work — discovery, thin slice, harden, handoff — mapped to the published engagement tiers, without fake day rates or open-ended retainers.
How I evaluate agent quality before handoff
A practical FDE playbook for evaluating AI agents before handoff — smoke tests, golden sets, retrieval checks, tool-call validation, guardrails, and a go-live scorecard that is not vibes on demo day.
The 80% of FDE work nobody demos
Most Forward Deployed Engineering is not the AI demo — it is SSO, legacy data, security review, and day-2 ops. The failure modes that kill production agents, and how to harden before handoff.