FDE vs. Presales, Consulting, Outsourcing, and Customer Success — What's the Actual Test?

If names are not correct, language will not be in accord with the truth of things; and if language is not in accord with the truth of things, affairs cannot be carried to success. — Confucius, The Analects, "Zi Lu"

"What's the difference between FDE and presales, or consulting?" gets asked constantly, and the answers never agree. Some say FDE understands the business better. Others say it leans more toward engineering.

Start with two roles. Both go into an enterprise customer and deploy an AI system that actually runs the business; both write code, connect systems, and watch outcomes. Company A calls the role "Solutions Engineer": he writes demo code, leaves once the deal closes, and bills travel on a per-diem basis. Company B calls similar work "FDE": the code goes to production, field experience flows back to the team, and pricing is tied to business results.

Look only at daily tasks, and the two job descriptions read almost identically. Look at the contract and how each is measured, and the responsibilities turn out to be entirely different.

This is common. FDEs at different companies can simply be different roles to begin with. The same person, moving to a different contract, can go from FDE to Solutions Engineer even if the day-to-day work doesn't change.

If the name can't define the role, what should?

I. Comparing Job Descriptions

The most intuitive approach is a table sorted by "does it write code, who is it for, when does it leave":

Role	Writes Code?	Who For	When They Leave
Software Engineer (SWE)	Yes, product code	Own company's product	Keeps iterating, never leaves
Presales / Solutions Engineer (SE)	Yes, demo code	Prospective customers	Leaves once the deal closes
Consultant	Mostly not; produces plans and roadmap docs	Customer's business side	Leaves after milestone sign-off
Outsourced / on-site developer	Yes, code the customer specifies	Customer project	Leaves when the contract ends
Customer Success Manager (CSM)	Mostly not	Signed customers	Ongoing service, never leaves

Presales can end up writing production code. A consultant can end up on-site for a year. An outsourced team can end up knowing the business cold. The table lists what a role usually does, and the exceptions live exactly inside that word "usually." Once the exceptions pile up, the table stops being useful for judgment — it's only good for reminding people not to assume (see Figure 2-1).

Figure 2-1: Roles that touch the same customer differ in where responsibility ends and whether experience flows back.

Why are these exceptions so common?

Jove Zhong, who heads AI Agent FDE at Cresta, put it this way: "Anything you can teach the customer to do isn't FDE."¹ He contrasts this with traditional SAP implementation. SAP's rules are explicit enough to write into a manual; once the customer learns them, their internal team can keep maintaining the system. That kind of work can be fully handed off — it sits closer to consulting or implementation.

AI agents, in his account, don't work that way. Even a customer with hundreds of engineers on staff may not be able to keep hallucination rates and response latency reliably under control. The problem isn't that the customer lacks documentation — it's that the judgment calls shift with the model and the scenario, so they can't be written into a manual once and for all. When that's the case, someone has to keep working the problem on-site.

That distinction exposes the table's hidden assumption: it treats "does it write code" and "who is it for" as fixed properties. But when the work gets too complex to hand off, the role's boundary shifts along with the project. What looks like Solutions Engineer work today may need a permanent on-site presence tomorrow. Any work that can be fully handed off — whatever it's called — eventually becomes a one-time knowledge transfer.

Since the work itself shifts, content alone can't define the role. This chapter looks at three observable tests instead: whether the code goes to production, whether field experience flows back into the product, and whether pricing is tied to effort or to results.

II. Test One: Where the Code Goes

First question: where does this person's code end up running?

Presales writes demo code to close a deal. Once the demo is over, that code has usually done its job. An FDE writes production code so the system keeps running — the code has to pass the customer's review, enter the deployment pipeline, and meet the customer's operational requirements.

The same line of code carries different weight depending on where it lands. A bug in demo code might cost a deal. A bug in production code might hit the customer's actual business.

AI coding tools have widened how much an FDE can touch directly. In the past, one FDE could barely keep up with multiple customers' codebases at once. Now, as long as he can state clearly what result he wants, AI can help him modify TypeScript, Swift, or database code¹. That doesn't just let him ship code to the customer — it also makes it easier to carry problems and fixes discovered on-site back into his own company's product line¹.

III. Test Two: Where the Experience Goes

Second question: once the project ends, where does what was learned on-site go?

Experience can end up in three places, each mapping to a different role.

The first: back into the product. The FDE carries requirements, problems, and reusable components discovered during customization back to the product team, turning them into capability the next customer can use directly. This is the path FDE experience is supposed to take.

The second: into a report. Experience gets written up as closing documentation and case studies, providing material for the next pitch. This is closer to project-based consulting.

The third: it stays in someone's head. When the person leaves, the experience leaves with them. This is common on outsourced projects.

Bhaulik Patel, who has studied this business structure closely, put it bluntly: an FDE organization where nothing flows back is, at bottom, "an expensive professional services organization hiding inside a software company"² — whatever the business cards say.

Run this test against a common Chinese setup: the FDE visits the customer, gathers requirements, builds a prototype on-site, and hands it to the backend team once confirmed. The experience stops at the handoff document. By this second test, that's closer to outsourced prototyping than complete FDE work³. That's not a knock on it — under certain procurement structures, this division of labor can make perfect sense (Chapter 18 unpacks this). The test is for locating a role, not judging it.

IV. Test Three: How It's Priced

Third question: is this role priced by effort, or by result?

Bill by the day, and the customer is buying time — how much that time produces is the customer's own call to judge. Bill by result, and the customer is buying an improvement in some outcome — the vendor also carries some of the risk that the outcome doesn't improve.

Neither model is inherently better, but each steers behavior differently. An organization billing by the day cares whether its people are fully utilized. A team billing by result cares more about whether the problem actually got solved. One AI delivery partner put it plainly: bill by the day, and the upside from any efficiency gain has nothing to do with you⁴.

Of the three tests, pricing is the easiest to verify — it's written into the contract and the invoice. A role can claim to care about customer success all it wants; how it's billed reveals what accountability it actually carries.

V. One Project, Three Different Structures

The following example exists purely to show how the three tests combine.

A retail company wants to deploy a "smart replenishment agent." Same project, three contract structures, three different roles growing out of it —

• Structure One: outsourced, billed by the day. The vendor sends two engineers on-site for six months, billed daily. Their code goes to production, but the experience stays with them personally; nobody guarantees the outcome, and hours worked are the deliverable. Against the three tests: ① production code ✓ ② no feedback ✗ ③ billed by effort ✓ — this is outsourcing, on-site or not.
• Structure Two: fixed-scope delivery plus a feedback clause. Same engineers, but the contract now states that "reusable components built during customization belong to the vendor and flow back to the product line." Experience starts flowing back, but accountability for the outcome still ends at sign-off. Against the three tests: ① ✓ ② ✓ ③ mixed — this is delivery with product accountability, already standing on FDE's threshold.
• Structure Three: revenue share on results. No fee unless the baseline improves; a share of the improvement beyond that. The vendor proactively cuts fake requirements and works only on what's measurable. Against the three tests: ① ✓ ② ✓ ③ billed by result ✓ — this is FDE with the complete responsibility structure.

What this demonstrates: what changes the role isn't the engineer, and it isn't the technology — it's the contract structure and where the experience goes. The same engineer, in three arrangements, carries three different kinds of accountability.

VI. The Three-Question Position Card

Collapse the three tests into a card — useful for self-assessment, or for turning back on an employer in an interview:

The Three-Question Position Card

1. Does this role's code go to production? (Ask the engineering lead: is last project's code still running? Who maintains it?)
2. Where does field experience go once the project ends? (Ask the interviewer: did the last project's custom components make it into the product line? Is there a "feedback review" mechanism?)
3. Am I measured by hours or by results? (Ask HR and the business lead: what metric does this role carry? Adoption rate? Retention? Or billable-day utilization?)

There's no standard answer to the three questions — what matters is whether the organization can answer clearly at all. An organization that can answer all three has at least a clear accountability structure, whatever the role is called. An organization that can't answer any of them has a role whose title, however new, says nothing about who's actually on the hook.

VII. Reality Is Messier

Time for honesty: fitting all three tests cleanly is an ideal type — reality is rarely black and white.

Most real-world roles are hybrids. Someone might spend seventy percent of their time on production code and thirty supporting presales; most organizations only manage partial feedback loops.

So use these tests for positioning and planning, not for pass/fail grading. First see clearly where you — or the role you're targeting — actually sit on all three tests. Then decide which direction to move, and what it will cost to get there.

The tests exist now, and they can locate a position. But once the position is located, a new question follows immediately: is this responsibility structure actually new, or is it something old wearing a new name?

---

Footnotes

1. Tencent Research Institute, AI Lens Roundtable, Episode 6: "FDE Non-Consensus Views and a Field Guide from Silicon Valley Founders" ↩ ↩² ↩³

2. @deployengineer (Bhaulik Patel), essay series ↩

3. "Anyone Out There Actually Doing FDE Work?" (linux.do thread) ↩

4. Crossroads × Rolling AI, "A Conversation on FDE" (podcast) ↩