Vetting an FDE provider: a buyer's checklist

This article is a tool for buyers, not a pitch. Take these questions to any provider you are considering, including us. A firm willing to answer them directly is usually the better partner anyway — because half of them cannot be improvised on the spot.

One premise: there is no recognised third-party certification and no authoritative ranking of FDE providers. Judgement has to come from asking. The list below runs in five gates, from “do we need this at all” to “when should we stop”.

Gate 1: ask yourself first

Before assessing providers, confirm that what you are buying is clear. Fail this gate and everything after it wastes both sides’ time.

1. Which measurable indicator will this improve? Not “improve efficiency”, but “this step takes twelve minutes and we want it under four”. If the indicator cannot be stated, acceptance will be a dispute.

2. Who holds the data, and can you get it? Does the data exist, can it be extracted, is it good enough to support a decision? This is the most common hidden blocker and the most frequent cause of delay.

3. Who will actually use the system? Have they been involved? If the answer is “IT is pushing it and the business side has not been involved”, the system will most likely go live and sit unused.

4. What happens if the judgement is wrong? Start with steps where a wrong answer can be caught by a human. Decisions touching money, safety or compliance should begin as assistance, not replacement.

5. Can anyone internally commit full time? Naming a domain expert and protecting their time is the single biggest variable in whether a project succeeds. If you cannot arrange it, do not start — this point recurs below.

Self-check verdict: if you cannot answer 1, 2 and 5, what you need is not an FDE. You need to work out the use case first.

Gate 2: is this worth embedding someone for?

6. Is the requirement a standard one? If a mature product already covers it, buying is cheaper and faster. The purpose of this gate is to talk you out of it — a provider that never turns anyone away either screens extremely hard or takes everything.

7. Why can your own team not do this? The honest answers are usually “nobody internally can commit full time” or “we lack someone who can translate business into technical work”. If the answer is “we could, we just do not have the time”, what you need is development capacity.

8. How long a validation window can you accept? If the business expects results in three months while assessment and pilot alone take one to two, align that expectation internally rather than pushing it onto the provider.

9. Can you absorb this failing? The possibility that a pilot investment comes to nothing is real. More than 60% of enterprise AI attempts stall at pilot stage. Decide your tolerance before you start.

Gate 3: is this provider actually doing forward deployed engineering?

This gate has the most questions, because a body shop and a genuine FDE team look almost identical from the website.

3.1 Are the people real?

10. Who will actually be assigned, and what have they done like this before? Ask about individuals, not the firm. “We will decide the team after kick-off” is a clear warning sign — it suggests you were sold by one team and will be delivered by another.

11. Has that person written code in the last two weeks? Roughly a third of roles titled “forward deployed engineer” are in practice pre-sales. This question separates “engineer who also faces the customer” from “pre-sales with a new title”.

12. What happens if that person leaves the project? A serious answer covers named personnel in the proposal, advance notice of any change, and a remedy or exit right for you.

3.2 Presence and authority

13. How much time will your people spend on our site, doing what? If the answer is “a weekly meeting”, that is a consultant, not an FDE.

14. Do they have decision authority, or does everything go back for approval? Without technical decision authority on the front line, every conversation doubles and throughput halves.

3.3 Compounding and reuse — the group that best separates real from fake

15. How much work does your first client take, and how much does your tenth in the same industry? The test comes from Bob McGrew, formerly of Palantir: if the first client takes ten person-months and the tenth still takes ten, the model has not worked.

16. When the project ends, what remains besides the system? A good answer names components, connectors, templates, evaluation sets. If the answer is “full documentation”, note that documentation is part of delivery, not compounding.

17. Have you ever advised a client against proceeding? Give an example. This one tests honesty. The answer should contain a specific situation and the reasoning, not “we always try to meet the customer’s needs”.

3.4 Handover design — the least-answered group in the industry

The sharpest framing of the risk is this: the danger is not using outside help; it is using it in a way that leaves the enterprise less capable and more dependent when the engagement is over. Almost no proposal raises the five questions below, and each one decides whether you can maintain the system yourself afterwards.

18. Who owns monitoring and logs? If you cannot see what the system calls, where it fails and whether quality is decaying, the visibility walks out of the door when we do.

19. Does the evaluation suite — data, pass criteria, scripts — transfer to us? Without it you cannot tell whether a change improved or degraded things, and you cannot confirm the system still works after a model upgrade.

20. In what form is integration logic and configuration delivered? If field mapping and exception handling live only in a configuration file that only you can change, we have not really received the system.

21. Is there a runbook and a decision record? How to handle common failures, which parameters must not be changed casually, and why it was designed this way. Without a decision record, the next person repeats mistakes we already made.

22. What does this cost to run each month, and what would make it jump? One figure is repeated across the industry: deployment is roughly 20% of the total cost, and the other 80% is keeping the system running through model upgrades, data drift and edge cases. Most proposals price the first part and treat the rest as a given.

A practical test: ask what you will and will not be able to change after they leave. If the answer contains a lot of “that would need us”, it is not a technical limit — it is a commercial design.

3.5 Role fit

23. Will you ever advise us not to proceed? In what circumstances? Without that mechanism, a provider will keep going after the direction stops making sense — because stopping costs them.

24. How many projects are you running at once? If one person is on five projects, the time and quality you get is calculable.

Gate 4: how to write the contract

25. Who sets acceptance criteria, and when? In writing, before work starts. The most common complaint in the industry is that acceptance slides indefinitely because “the client asked for one more change”.

26. If a key assumption fails halfway, how do we settle? Phased settlement with the option to stop shows confidence in their own judgement; full prepayment or day-rate settlement puts the risk on you.

27. How is scope creep handled? The right answer is “changes are recorded as input to the next phase and not absorbed into this one”. Scope creep is the leading cause of pilot failure.

28. How are data access scope, identity and audit trails specified? It has to land in clauses: who may see what, under which identity, how long logs are retained, and whether you can retrieve them on demand.

29. Are we on a fixed price or a quantity of work? Fixed price is not automatically safer — audit findings note that fixed pricing incentivises a thin evaluation suite, because evaluation work saved becomes the provider’s margin while the performance risk stays with you.

30. Who owns it after launch, and what is the response time when it breaks? Many AI projects die in the three months after launch. Delivery without a named owner and a response commitment is incomplete.

Gate 5: when to stop

If any of these appears, pause rather than invest further:

1. Personnel are never named, or the counterpart keeps changing
2. Only capability is discussed, never limits — they never say what they cannot do
3. They refuse to write acceptance criteria, or keep deferring “until it is built”
4. The data boundary is unclear, or they say they will train models on your data
5. The demo is impressive but there is no method for evaluating on real data
6. One person answers everything, and is plainly not the person who will deliver
7. Handover questions are deflected, or the answer is “you do not need to worry about that”
8. Promised indicators are adjectives only (“significantly better”, “substantially lower”), with no measurable definition

One-page summary

Gate	Core question	If it fails
1. Self-check	Indicator, data, users, recoverability, internal capacity	Work out the use case first; do not hire yet
2. Worth embedding?	Standard requirement? Why not in-house? Timeline? Tolerance for failure?	Buy a product, or build internal capability first
3. Is the provider real?	People, presence, authority, compounding, handover design	Change provider, or narrow to a single-scenario pilot
4. Contract	Acceptance, settlement, scope change, data clauses, maintenance	Do not sign; settle the clauses first
5. Red flags	The eight above	Stop and reassess immediately

One last honest point: the main value of this checklist is not finding the best provider — it is ruling out the unacceptable ones. In an industry with no agreed standard yet, being able to eliminate half the field is already a large improvement in decision quality.

---

If you are assessing several providers, run gate one on yourself first. If the conclusion is “we need to work out what we are doing”, that is precisely what our assessment is for. If you simply want a second opinion, get in touch. Two related pieces: FDE vs outsourcing and When does a company actually need an FDE?.