
Three proposals land on your desk for the same need. The first mentions a POC, the second a pilot, the third an MVP. All three promise to check whether AI is worth anything in your business. None describes the same thing. Signing the cheapest one can cost you more than the most expensive one, because the invoice that matters is not the prototype: it is the one that starts after the demonstration.
Key Takeaways
- A POC tests a technical hypothesis. It does not produce a usable service.
- A pilot measures a gain on a real scope, with real users and a baseline indicator.
- An MVP puts a service into production with its support, monitoring and exit path.
- The price gap between the three rarely comes from development: it comes from what the proposal includes after the demo.
- According to Gartner (2024), at least 30% of generative AI projects will be abandoned after the proof-of-concept stage. So the question to ask before signing is simple: what happens if we stop?
Three formats, three different questions
A POC answers a feasibility question: can this work on our data, with our constraints? The deliverable is a demonstrator and a note. Nobody uses it in daily work, and nobody promised they could.
A pilot answers a value question: does it produce a measurable gain when real people use it on real tasks? The deliverable is a tool in service on a limited scope, with a measurement before and after.
An MVP answers an operating question: what is the smallest version that can deliver the service continuously, without collapsing at the first incident? The deliverable is a service used by real users, monitored, documented, and with a known way to replace it.
That difference in question produces a difference in invoice. It is not proportional to development effort. It is proportional to everything that has to be added before a demonstrator becomes a tool your company can leave running.
| Format | Question asked | Main deliverable | Who uses it | What remains to pay afterwards |
|---|---|---|---|---|
| POC | Is it technically feasible? | Demonstrator and feasibility note | The project team | Integration, security, support, training |
| Pilot | What gain on a real scope? | Tool in limited service and gain measurement | A small group | Scaling up, support, licences |
| MVP | What minimum service survives production? | Usable, monitored, documented service | Real users | Maintenance, changes, model migrations |
What you actually pay for in a POC
A POC is invoiced across four items, in an order of weight that often surprises executives.
The first is data preparation. Extracting samples, anonymising, building a representative test set: it is rarely glamorous and almost always the heaviest item.
The second is technical iteration. Instruction design, task breakdown, model comparison, answer evaluation. A serious POC is judged on the quality of its evaluation protocol, not on the beauty of a demo.
The third is model consumption. It stays modest at this scale, but it exists and it varies. A proposal that calls it "included" with no cap deserves a careful read.
The fourth item almost never appears on the quote: your own time. A POC mobilises your business experts to define cases, review answers and decide which errors are acceptable. That cost is real, it comes out of your payroll, and it is the first cause of delay.
What a POC does not include, by definition: integration with your information system, authentication, logging, compliance, training, support. That is not a dishonest omission. It is the definition of the format. The problem starts when the proposal sells a POC and lets you believe it will be enough to put the service into production.
Gartner places the cost of generative AI deployment approaches between $5 million and $20 million for business model transformation projects, an order of magnitude that concerns large groups, not an SME. The useful lesson is not the amount, it is the reason Gartner gives: abandonment after POC comes from data quality, inadequate risk controls, escalating costs or poorly defined value. Three of those four causes are decided before signature, not during development.
The pilot: the invoice changes in nature
A pilot adds three things a POC does not have, and each one has a price.
First, scope. You have to pick a process, a number of users, a volume of cases, and stick to it. A pilot that widens mid-course becomes a project, with a project budget, without the guardrails.
Then measurement. A pilot without a baseline defined in advance is a POC in disguise, invoiced higher. The baseline is taken before kickoff, on data you agree to look at: processing time, error rate, number of back-and-forth exchanges, customer response time. Without that initial picture, the final demonstration will conclude on impressions.
Finally, partial integration. The pilot has to touch your tools, even modestly: a mailbox, a CRM, a business application, a shared folder. That is where the technical proposal meets the reality of your access rights and your data. It is also where recurring costs become visible: licences, model consumption, hosting, test environments.
Two more items are easy to forget. Change management, with user training and the appointment of internal champions. And the legal frame: informing employees, processing register, data processing agreement with the model provider, retention period for exchanges.
At this stage the right question is no longer "how much does the pilot cost" but "how much does the pilot cost, and the decision that comes with it". A successful pilot with no prepared follow-up ends as a report nobody reads.
The MVP: the heaviest expense is no longer development
When a service goes into production, the split of spending reverses. Code becomes a shrinking share. What weighs is what keeps the service running.
Monitoring: who reads the logs, who gets the alert when an answer is empty or absurd, with what response time.
Model lifecycle: providers regularly deprecate and replace their versions. A service built on a frozen version must plan retesting at every change, otherwise quality degrades without anyone deciding it should.
Continuous security and compliance: access rights, personal data in logs, successive subcontractors, retention.
Documentation and handover: a company that cannot explain its own tool becomes dependent on whoever can.
Reversibility, finally. Who owns the code, the instructions, the evaluation sets, the prepared data? What happens if the provider disappears or you change supplier? That exit cost is negotiated before signature, never after. On this specific point, the reversibility clauses of an AI agent are worth reading before comparing entry prices.
The context makes this review more necessary than it looks. According to Gartner (2025), over 40% of agentic AI projects will be canceled by the end of 2027, because of escalating costs, unclear value or inadequate risk controls. The same release estimates that of the thousands of vendors presenting themselves as agentic, only about 130 really are. In other words: part of what you pay at MVP price may only be a renamed assistant.
What the displayed price does not say
Two proposals at the same amount can hide opposite commitments.
Billing structure first. A fixed price protects you from overruns but pushes towards a reduced scope. Time and materials leaves you in control but transfers the risk to you. A subscription looks light in year one and becomes heavy once the service is indispensable. Always compare the cost of year two, not just year one.
Milestones next. A proposal with no written acceptance criteria, paid on delivery of a "working prototype", leaves you as sole judge of a disagreement. Criteria must be measurable: correct answer rate on a test set defined in advance, processing time, accepted human escalation rate.
Intellectual property. Instructions, test sets and evaluations are assets. If they stay with the provider, you are funding the construction of know-how you do not own.
Outcome commitment. Few providers agree to sign one on a subject where quality depends on your data. A properly described commitment of means is worth more than a vague promise of results. See what an AI agent quote must contain for the list of clauses to demand.
Public funding, finally. The French research tax credit covers 30% of eligible R&D expenses up to 100 million euros, according to the Ministry of the Economy. Experimental and prototyping work may qualify, a standard deployment much less so. The calculation belongs with your accountant, before signing, not at filing time.
Four questions to separate two proposals
- What exact deliverable, and who uses it on the last day of the contract? If the answer is "the project team", you are buying a POC, whatever the cover says.
- Which indicator is measured, and what is its starting value? Without a baseline there is no gain, only an impression.
- What happens if we stop? Exit cost, data recovery, ownership of code and instructions, length of the transition period.
- What does year two cost? Licences, consumption, support, maintenance, retesting caused by model changes.
A serious provider answers those four questions in writing before you sign. A provider who finds them premature is asking you to pay to find out.
If you are preparing the ground upstream, an AI project brief makes those answers comparable from one proposal to the next.
FAQ
Is a POC always necessary?
No. It is necessary when the uncertainty is technical: incomplete data, uncertain quality, many edge cases. It becomes pointless when feasibility is already proven by comparable uses and the real question is adoption by your teams. In that case, a badly scoped pilot will teach you more than a successful POC.
Can you go straight to an MVP?
Yes, provided you accept that the MVP carries the uncertainty for you. You then pay to learn in production, with real users, which is sometimes the only way to get a reliable answer. The price of that shortcut is a higher operating risk at launch, and a design debt you will have to address.
Why do two providers quote very different prices for the same POC?
Because the word POC does not describe a scope. One invoices a demonstration on data you prepared, the other an evaluation on real data with a measurement protocol and a limitations report. The second costs more and often avoids a pointless follow-up project.
Who pays for licences and model consumption?
That is a contract question, not a technical one. A proposal that includes them with no cap protects itself with a usage limit; a proposal that excludes them must give a monthly order of magnitude. Ask for the cost per user per month, and the volume at which it changes in nature.
Can an AI POC qualify for the research tax credit?
It can, if the work counts as R&D under tax law: search for new solutions, test protocols, documentation of technical obstacles. Integrating an existing tool generally does not qualify. Eligibility is prepared with your accountant and documented during the project, not afterwards.
Conclusion
The difference between a POC, a pilot and an MVP is not a difference in size. It is a difference in responsibility. A POC tells you whether it is possible. A pilot tells you whether it is worth it. An MVP commits you to running the service, with its support, its recurring costs and its exit.
The displayed price rarely measures that. It measures what the provider agreed to write down. Before comparing three amounts, ask for three scopes, three indicators and three exit costs. You will often find that the cheapest proposal is not talking about the same project.
NexeAI works on these three formats for SMEs: scoping and an AI audit to settle feasibility, a pilot on an identified process, and the move to production of an AI agent or an automation with running costs written in plain terms. The first step is to describe what you agree to pay, and what you refuse to pay twice. Let's talk about your project.


