Presales and scoping AI work
“Presales or estimation experience” on an engineering job ad means the role sits next to the sales conversation: you will be in the room before the contract, asked whether the thing can be built, for how much, and by when — about a system whose accuracy nobody knows yet. This note is how to do that honestly, and how to talk about having done it.
Working directly with clients covers the relationship once the work has started; this is the part before.
What presales actually is
An engineer in presales does four things sales cannot:
- Qualifies the problem. Is there data, is there a number that defines success, is the cost of a wrong answer survivable? A “no” to any of these is a project that will fail after the contract, and saying so before it is the most valuable thing you can do for the company.
- Reframes the ask. “We want an AI that reads all our documents” is a solution; the problem is usually “three people spend their week keying invoices”. Work back to the process (Process mapping and choosing what to automate).
- Shapes the engagement into phases with exits.
- Estimates, with the uncertainty visible.
The failure mode is the engineer who answers “can you build it” with “yes” and leaves the room. Everything can be built; the question is at what accuracy, for what cost, with how much human review, and whether the client would still want it at those numbers.
The shape that survives contact
discovery ─▶ pilot ─▶ MVP ─▶ production ─▶ operate
(days) (2-3 wk) (6-10 wk) (per scope) (monthly)
│ │
│ └─ produces: golden set, measured accuracy,
│ review rate, cost per document, a re-quote
└─ produces: problem statement, success metric,
data inventory, risk register, phase planThe pilot is the load-bearing phase. It is short, fixed-price, and its deliverable is numbers — field accuracy on the client’s own documents, the review rate, tokens and dollars per page — plus the labelled set that produced them. Then the MVP is quoted against measurements rather than hope. Clients accept this readily when it is framed as de-risking their spend, and the ones who refuse a pilot are telling you something.
Estimating AI work
Software estimation techniques (Estimation and Planning) assume the work is knowable; ML work has a component that is not — how good the model will be on this data — and the estimate has to say so.
- Split the estimate. Engineering (pipeline, integration, UI, ops) is estimable and dominates the hours; model quality is a measurement, not an estimate, and the pilot buys it.
- Data readiness drives the timeline more than anything technical. No labelled examples, documents locked in a system with no export, PII that cannot leave the country: each is weeks, and none shows up in a feature-based estimate.
- Give ranges with the drivers named. “Six to ten weeks; the low end if the ERP has an API and you can provide 300 labelled invoices in week one.” A range with drivers is a plan; a point estimate is a promise.
- Price the review team. Human review at 10% of volume usually costs more than the GPUs, and it is the line clients forget until it arrives.
- Buffer the project, not each task, and say the buffer out loud.
For infrastructure, the arithmetic is in Sizing GPUs against an SLA and a budget: tokens per page, throughput per GPU, the SLA, and a range the pilot narrows.
The demo
The demo sells the project and creates the expectation you will be judged against. Rules:
- Demo on their documents, obtained before the meeting, not on the clean sample from the vendor’s website.
- Show one failure deliberately, with the review screen that catches it. A demo with no failures sets up the “but it worked in the demo” conversation; a demo that shows the safety net sells the safety net.
- Say the accuracy number you measured and the size of the sample, not “it works great”.
- Never demo a model whose licence you could not ship under (Open-weight VLMs: the landscape).
Writing it down
The statement of work is where presales becomes an engineering artifact. What belongs in it, because each one has ended a project when it was missing:
| Section | Why it is there |
|---|---|
| Success metric, with number | defines done |
| Data the client provides, by date | the schedule depends on it |
| Accuracy target and review rate | prevents “but it should be 100%” |
| Out of scope, explicitly | the invisible stakeholder’s wish list |
| Phase exits and re-quote points | the pilot’s job |
| Operating cost after go-live | GPUs, reviewers, on-call |
| Assumptions and risks | what changes the estimate |
The assumptions list is the most useful section and the one most often skipped: “assumes documents are machine-printed; handwritten forms are out of scope for the MVP” is one line that saves a month.
Saying no, and the smaller thing
Some opportunities should be declined, and the engineer is the one who knows: no data and no way to get it; an accuracy requirement that no review process could meet; a timeline set by a conference date rather than the work.
The move is the same as with a client in delivery — restate the goal, name the risk, propose the smaller thing that tests it (Working directly with clients). In presales the smaller thing is almost always a pilot, and a pilot declined is a project avoided.
Related
Interview angle 4
- “Tell me about a time you scoped an AI project for a client.” - the story has a reframe (their solution to the real process), a qualification (data, metric, cost of error), a pilot with numbers, and a re-quote. End with what the pilot changed about the estimate; that is the evidence you did it rather than sold it.
- “How do you estimate something whose accuracy you do not know?” - split it: engineering hours are estimable and dominate; model quality is measured in a short fixed-price pilot on the client’s data, and the MVP is quoted on the measurement. Ranges with the drivers named, review-team cost included. Follow-up: what if the client wants a number today? A range with the assumptions written down, and the pilot as the first phase of the contract.
- “How do you demo without over-promising?” - their documents, one visible failure with the review screen, the measured accuracy and sample size said out loud. The demo shows the safety net, not just the model.
- “When would you advise against taking a project?” - no data and no path to it; an accuracy requirement no review process could meet; a deadline set by an event. Say it early, propose a pilot as the smaller thing, and let the pilot’s numbers make the case either way.