On this page
Yes or no, with numbers attached
A proof of concept, or PoC, answers one question before money goes into the full product. The answer is yes or no, with numbers attached. Can a model read our handwritten job sheets? Will our old accounting package talk to a new planning tool? Can the server take ten thousand messages an hour? Those are proof of concept questions.
What a PoC is not: a first version for users. There is no polished screen, often no login, and the code may be thrown away. What remains is knowledge: whether it can be done, under which conditions, and what building it for real will cost. In software development, that is the cheapest insurance you can buy before signing a larger contract.
An engineering term, with a fixed place at NASA
The phrase has a fixed place in how engineers measure technology maturity. NASA uses nine Technology Readiness Levels: at level 3, active research and design begin, and that is where a proof-of-concept model is often built. Only after that are components tested together. The European Commission adopted the same scale for Horizon 2020; in its 2014-2015 work programme, level 3 is literally experimental proof of concept, and level 9 a system proven in operation.
Europe funds the step too. The European Research Council gives researchers a Proof of Concept Grant of 150,000 euros for 18 months to test whether an idea from their research can become a product or a service. In business software the scale is smaller, but the question is the same: does it work, before we build?
200 job sheets as the bar
The test in four steps
- 01One questionCan AI read our paper job sheets well enough to stop retyping them?
- 02The bar, set first95 percent correct per field on 200 real sheets from last month.
- 03The testPhotos through a model, output next to what the office typed.
Result on 200 job sheets
Scale from 80 to 100 percent
Client and address98%
Date99%
Hours worked96%
Materials and quantities87%
Below the bar: abbreviations and crossings-out
Signature present97%
Bar: 95 percent correct
An example, not a client. Four fields clear the bar; materials do not. The decision: build the app for hours and clients, and pick materials from a list instead of reading them.
Proof, prototype or first version
All three start small, but each answers a different question. The MVP is the smallest version real users already use every day; the prototype shows how it looks and behaves; the proof of concept proves it can be built.
| Form | The question | For whom | With real data | Typical length | What remains |
|---|---|---|---|---|---|
| Proof of concept | Can it be done? | The build team and the decision maker | Yes, a sample | One to three weeks | A number, a decision, sometimes reusable code |
| Prototype | Do people understand it? | Testers and the client | Usually not | Days | Screens and feedback, often starting from a wireframe |
| MVP | Do people use it? | A small group of real users | Yes | Six to twelve weeks | A product to build on |
The order is not sacred. If the technology is well known, say a web application with forms and a database, skip the proof of concept. If everything hangs on an integration with someone else's software, or on an AI model reading your documents, start with one. Weighing whether to build at all? Our comparison of build vs buy helps you decide before the PoC.
AI tested on 200 real documents first
In AI work a proof of concept is nearly always step one, because you only know how well a model performs once it meets your own documents. A vendor demo on its own examples says little about your handwriting, your abbreviations and your exceptions.
Take an installation company with six engineers. About 120 paper job sheets come in every week, and someone in the office retypes them: three minutes a sheet, six hours a week. The PoC question: can an AI model read a photo of a job sheet well enough to stop the retyping? The bar is fixed first: 95 percent correct per field on 200 real sheets from last month, compared with what the office typed.
The outcome in the example: client, date, hours and signature clear the bar; materials do not, because of abbreviations and crossings-out. The decision is not yes or no but a better question: read what works, and let engineers tick materials from a list in an app instead of writing them. The PoC also shows what does not need AI at all. Belgian suppliers have sent structured e-invoices to each other since 1 January 2026, over Peppol; a UBL invoice is read as data, no model needed. Our guide to e-invoicing in Belgium explains the rules.
Without a bar a test proves nothing
Agree before the test what counts as good enough, on which data and who decides. Whoever defines success afterwards will always find a reason to carry on.
Five to six working days, and what that costs
The cost is time, not software. Take the job sheet example with an assumed day rate of 600 euros. One day to set the question, the bar and the 200 sheets. Two to three days to build the test: photos in, fields out, side by side with the retyped version. One day to measure and one to prepare the decision. Five to six days in all, 3,000 to 3,600 euros.
The model itself costs next to nothing. A photo of 2000 by 1500 pixels counts as about 1,564 tokens for Claude; add the instruction and the answer and you get roughly 2,100 input and 300 output tokens per sheet. At Claude Sonnet 5.5 prices, 2 dollars per million input tokens and 10 dollars output, that is 0.7 cents per sheet: 1.44 dollars for all 200, about 1.29 euros. How those tokens add up for other models, you can check with our AI cost calculator.
Set against those 3,000 euros is the risk you avoid. Six hours of retyping a week, at 40 euros an hour in wage cost and 46 working weeks, is 11,040 euros a year. If the solution works, that is the gain. If it does not, you know after a week rather than after a 20,000-euro project. Writing the larger project down afterwards is easier with a software requirements template.
Ground rules for day one
- One question, one sentenceNot "AI for our admin" but "can a model read our job sheets correctly".
- Real dataA sample of your own work, ugly cases included, not the ten best examples.
- A bar in numbersWhat good enough means per part, and what you compare against.
- A fixed time boxOne to three weeks. If it overruns, that is a result too.
- A decision dateBuild, adjust or stop, and who makes that call.
Before you start a test
What does PoC stand for?
In software and projects, PoC means proof of concept, a test that proves something can be done technically. In healthcare the same letters mean point of care, a test at the patient's side such as a quick glucose reading. Context tells you which one is meant.
What is the difference between a proof of concept and a pilot?
A proof of concept tests the technology, usually outside daily operations. A pilot runs a working solution for a while in part of the business, with real users, to see if it holds up in practice. A pilot comes after the proof of concept and looks more like an MVP.
What if the proof of concept fails?
Then it did its job. You learn for a fraction of the price that the idea does not work this way, and often why. Usually a smaller or different question follows: another model, fewer fields, or a form instead of a photo.
Who owns the code of a proof of concept?
Put it in the contract. If you commission and pay for a PoC, the code and the measurements should be yours, so you can continue with another supplier if you want to.