The Deal Before the Build: Why FDEs Belong in the Sales Process

The balance between selling too much and selling nothing at all.

Two complaints I hear constantly.

From sales: “Why does my technical team keep killing deals?”

From delivery: “Why do we keep selling things we can’t deliver?”

Both are valid. Both come from the same root problem: the wrong people making decisions alone.

Here’s what I’ve learned about where FDEs fit in the sales process, and why that positioning matters more than most companies realize.

The Balance Nobody Talks About

Sales people live in possibility. Their job is to see what could be, to paint a picture of transformation, to get a yes. That optimism is a feature, not a bug. Without it, nothing gets sold.

FDEs live in reality. We see the API that doesn’t exist, the edge cases that will eat three weeks of development time, the “simple integration” that requires direct database access because there’s no proper interface.

Neither perspective alone produces good outcomes.

When only sales drives the process, you end up selling solutions that aren’t technically feasible. Or solutions that technically work but require four times the resources anyone budgeted for. I’ve been on projects where we had to bypass an entire integration layer and work directly with underlying databases because the API we were promised didn’t exist. That’s not a small adjustment. That’s a fundamentally different project with fundamentally different risks.

But here’s the thing about ignorance being bliss: if FDEs were the sole decision makers, we’d sell almost nothing.

We see complexity everywhere. We envision all the directions a solution could go, all the ways scope could expand, all the edge cases lurking in the shadows. That awareness is valuable during delivery. During sales, it’s paralysing.

I’ve been talked into deals I would have walked away from. The sales person recognized that the customer would be happy with a fraction of what I was imagining. They were right. We delivered value. Everyone won.

The magic happens when both perspectives collide.

When to Bring in the FDE

Timing matters. Too early, and you waste technical resources on deals that were never going to close. Too late, and you’ve already promised things you can’t deliver.

The trigger should be likelihood of closing. When a deal moves from exploratory to probable, that’s when FDEs add value.

For me, involvement typically means one or two calls plus technical discovery. Those calls are about understanding the actual workflow, the actual pain points, the actual data. The technical discovery happens separately: checking if APIs exist, whether data is accessible, what integration points look like.

This takes hours, not days. But those hours prevent weeks of pain later.

What the FDE Actually Does in Pre-Sales

My job in the sales process comes down to one question: what brings the most value to the customer while taking a reasonable amount of resources to build?

That’s the only question that matters. And answering it requires understanding both sides of the equation.

On the value side, I try to understand where the customer currently spends the most time and resources. Time saved is the currency of the AI era. Tasks that required throwing bodies at them seven years ago can now be automated. But which tasks? That’s what discovery reveals.

You’d think customers know where they spend their time. Often they don’t. Or they think they know but they’re wrong. Guiding them through this is part art, part process. We figure it out together.

On the effort side, I’m assessing risks. Can we actually integrate with their systems? Do they have clearly defined SOPs? Is there enough data to warrant building a solution?

That last part is crucial. AI needs context and guidance. We need examples of input data and expected outcomes. As many pairs as we can get. Sometimes 25 is enough to start. Sometimes we need thousands. It depends on the complexity.

When a customer can’t explain how their process currently works, or where their pain points are, that’s a red flag. It usually means they’ve bought into the hype that AI will magically figure things out. We’re not there yet. Maybe we never will be.

If they don’t have examples, if every case is “different,” if they can’t articulate what good looks like - it might not be a good match. Better to know that before contracts are signed.

The Proposal: Where It Comes Together

The FDE typically writes the solution proposal. Then we discuss pricing based on complexity, timeline, and value created.

This is where the balance becomes concrete. The sales person knows what the customer will pay, what competitors are offering, what urgency exists. The FDE knows what can actually be built, how long it will take, what risks need to be mitigated.

Neither has the full picture alone.

What I’m trying to produce at this stage is a proposal where I can estimate the resources needed for each individual component. No black boxes. No hand-waving. If I can’t break it down, I don’t understand it well enough to sell it.

The Hidden Benefit: Continuity

Here’s something that doesn’t get discussed enough: the FDE who sells the solution is usually the same person who builds it.

That continuity changes everything.

When a sales engineer hands off to a delivery team, information gets lost. Context disappears. The delivery team discovers constraints that were never documented. They make assumptions that don’t match what was discussed.

When the same person who scoped the project builds it, that handoff problem vanishes. I remember the conversations. I remember what the customer emphasized, what they dismissed, what they got excited about. I remember the risks I flagged and the tradeoffs we discussed.

That memory is worth more than any documentation.

Setting the Tone for What Comes After

The most important thing that happens in pre-sales isn’t scoping or pricing. It’s setting expectations.

AI projects don’t work like traditional software delivery. They require continuous refinement. The initial deployment is the beginning, not the end. Scope will evolve as we learn what actually works.

This needs to be established before the deal closes.

I also try to establish the 80/20 reality upfront. There’s usually a core set of features that delivers the vast majority of value. Getting the remaining 20% often costs four times the resources. Diminishing returns are real.

When customers understand this from the start, they make better decisions throughout the project. They prioritize ruthlessly. They don’t get upset when we recommend stopping at “good enough.”

When they don’t understand it, every conversation becomes a negotiation about scope creep.

What I Collect Before Day One

Assuming everything goes well and the deal closes, there’s a critical window before the project officially starts. This is when I try to gather:

Input/output pairs. Examples of data coming in and what the ideal result looks like. The more the better.

SOPs. How does the process actually work today? What are the steps? Who does what?

Priority stack. What’s critical versus nice-to-have? If we can only deliver three things, which three matter most?

Communication preferences. How will we collect feedback? Who’s the decision maker? How often do they want updates?

This information shapes everything that follows. Missing it means starting the project with gaps that will slow us down later.

The Question Nobody Asks

Companies building AI practices obsess over technical capabilities. Can we fine-tune models? Do we have the right infrastructure? Can we handle scale?

They rarely ask: do we have the right people in the right rooms at the right time?

An FDE in the sales process isn’t overhead. It’s insurance. Insurance against selling the unbuildable. Insurance against missing risks that blow up timelines. Insurance against starting projects without the context needed to succeed.

The companies that figure this out close better deals and deliver better outcomes.

The ones that don’t keep asking the same two questions:

“Why do we keep selling things we can’t deliver?”

“Why does my technical team keep killing deals?”

The answer to both is the same: because they’re not in the room together when it matters.