Answering the Feasibility Question Cheaply

Ask one question

“Can we extract these eight fields from these documents at above 85% accuracy?” is a question. “Can AI help our finance team?” is a topic.

The narrower the question, the more decisive the answer, and the cheaper it is to get.

What it must include

1. Your real data, including the awkward cases
2. An agreed definition of correct, written before the work starts
3. A measured result, not an impression
4. An honest account of what failed and why

A proof of concept that produces a percentage and a list of failure modes is worth the money. One that produces a demonstration on three chosen examples is worth nothing.

What it should skip

• Polished interfaces — the output can be a spreadsheet
• Integration — nothing needs to be written anywhere yet
• Scale — a hundred documents answers the question
• Production concerns — those belong to the build

Spending proof-of-concept budget on any of those means spending it on the wrong question.

The output document

Stopping is a good outcome

If the proof shows the accuracy ceiling is too low to justify a build, you have spent a few thousand pounds instead of thirty.

We have written that recommendation more than once. It is the reason the recommendation to proceed means something.

Frequently asked questions