AI proof of concept
Test the idea on a real task.
Build the smallest experiment that can show whether an AI approach is useful under your data and operational constraints.
Discuss your question
A prototype should settle a question.
You may know what an AI feature should do but still be unsure whether it can handle your material. A demonstration with a few convenient examples will not resolve that uncertainty.
We build a limited proof of concept around an agreed task, with a baseline and assessment criteria defined before the result. For example, can an approach extract the right fields from permitted documents while recognising when a field is missing?
This suits teams with a defined question and access to useful examples. If those are not yet available, start with research and feasibility. A prototype is an experimental artefact, not a production service.
From assumption to evidence
Build only what the test needs.
Agree the claim and baseline
Describe the behaviour being tested, the simpler alternative and what would count as failure. Keep the task small enough to interpret.
Prepare the examples
Separate development material from assessment examples where possible. Include missing evidence, exceptions and ambiguous inputs, with permissions agreed.
Build and examine
Create the necessary interface or technical path. Review intermediate behaviour with the people who understand the task, without silently changing the final test.
Report the result
Explain successes, failures, sample limitations and the practical work still required. Recommend proceeding, revising or stopping.
What you receive.
- An agreed experiment brief and acceptance criteria.
- The limited prototype and shareable project code.
- Documented examples, configuration and assessment method.
- A comparison with the agreed baseline.
- Failure examples and a record of limitations.
- A recommendation and remaining engineering questions.
What stays outside the experiment
Production hosting, ongoing monitoring, full security assurance, extensive integration and operational support are not implied by a working prototype. Any included controls are stated in the scope.
Keep human judgment visible
If the proposed workflow affects a customer or business record, the experiment should examine how review works and where it can fail. Adding an approval button is not, by itself, evidence of safe operation.
Our worked evaluation example shows how an apparently helpful answer can still add an unsupported claim. See also how to define success criteria.
Before we start
A scope you can make a decision on.
Scope, fee and timing
The main cost drivers are data preparation, the number of approaches compared, interface requirements, integration access and the amount of domain review. A single workflow with an agreed boundary is usually easier to scope than an open-ended product prototype.
We agree the question, deliverables, exclusions, fee and review dates in writing before work begins. Data access and reviewer availability affect the schedule. If the question changes, we agree the change before extending the work.
What we need from you
An agreed task, permitted examples, a domain reviewer and a technical contact where systems access is needed. If only synthetic examples are available, the resulting limits must be part of the brief.
Handover and the next stage
The handover includes the agreed report, methods and shareable project artefacts. Ownership, third-party licences and data permissions are settled in the engagement terms. Production implementation, hosting and ongoing support are separate decisions; the findings can go to your own engineers or an implementation partner.
Is a proof of concept the same as an MVP?
No. A proof of concept tests an assumption. An MVP is intended for actual users and needs an operational scope, support and appropriate safeguards.
Can you use our own data?
Yes, where permission, access and handling arrangements are agreed. The scope states what is processed, where, and what is retained.
What happens if the prototype fails?
The findings should explain which assumption failed and whether another experiment is justified. A clear stop decision can prevent a larger unsuitable investment.
Can our engineers take the work forward?
The agreed code, methods and findings are handed over with ownership and licence terms made explicit. Remaining production work is identified rather than assumed complete.