What a proof of concept is for
One question: is this approach accurate enough on your actual data to be worth building? Not whether people want it, not what the interface should look like — just whether the core capability works.
That question can be answered in a fortnight and it is the one that sinks projects when it is skipped.
What the two weeks contain
- Days 1–3: collect fifty to two hundred real cases and agree the correct answers with your expert
- Days 4–7: build the pipeline — extraction, retrieval or classification as appropriate
- Days 8–10: measure, per field and per category, and try the obvious improvements
- Days 11–14: write up what it achieves, what would improve it, and what a build would cost
What it deliberately excludes
- Any interface beyond what is needed to see the results
- Integration with your systems
- Authentication, permissions, deployment
- Anything you would show a customer
A proof of concept that looks like a product has spent your money on the wrong things. It should look like a spreadsheet of results, because that is what answers the question.
What you can conclude
If accuracy is well above what the process needs, build with confidence. If it is close, we will tell you which specific improvements would close the gap and roughly what they cost.
If it is far below, the honest conclusion is that this problem is not ready, and you have spent a fortnight rather than a quarter finding out.
The evaluation set survives
Whatever the outcome, you keep the cases and the agreed answers. That set is reusable by any supplier, and it is the thing that makes future model changes an afternoon rather than a project.
It is frequently the most durable output of the two weeks.