Home / AI glossary / What is an AI proof of concept (PoC)?
AI glossary

What is an AI proof of concept (PoC)?

A proof of concept answers whether something can work at all.

In short

An AI proof of concept is a small, quick build that tests whether a specific AI idea actually works technically. It uses limited data and scope to answer one question: can this be done? A PoC is deliberately low-cost and disposable, so a business learns whether to invest further before committing to a full, production-grade system.

A proof of concept (PoC) is a deliberately small build with one job: establish whether an approach can work at all, before anyone commits budget to making it work well.

It is the least expensive question in the sequence, and the one most often skipped or conflated with the two that follow it. PoC, pilot and MVP answer different questions and have different exit conditions, running one while believing you are running another is a reliable way to overspend.

PoC vs pilot vs MVP, the distinction that saves money

A proof of concept asks can this work? and can be answered on sample data, in a lab, by one engineer. A pilot asks does this work here, with our data and our people? and can only be answered inside the business. An MVP asks will people use and pay for this? and is a product you intend to ship, support and maintain. The PoC and pilot are experiments you plan to throw away; the MVP is the first version of something you plan to keep. Scoping an experiment as though it were a product is how a two-week question turns into a two-quarter commitment.

When you should skip the PoC entirely

If the technology is demonstrably proven for your use case (document extraction, transcription, classification of common document types), then can it work is not in question, and a PoC only delays the useful experiment. Go straight to a pilot. Keep the PoC for genuinely uncertain cases: an unusual data format, a domain where published accuracy is poor, a physical process where feasibility depends on conditions no specification captures. Paying for a PoC to confirm something the industry settled two years ago is a common and avoidable expense.

What a proof of concept must produce

Not a demo. A demo shows the happy path to people who want to be impressed. A useful PoC produces a documented answer with its conditions attached: it worked at this accuracy, on this kind of input, and here is where it broke. The failure cases are the deliverable. A PoC that reports only success has usually been run on data selected to succeed, which tells you nothing you can act on and quietly moves the risk into the production budget.

What a proof of concept should cost

At Crux Digits a €20,000 Production-ready MVP runs 4–6 weeks on your real data, preceded by a €2,500 audit that establishes whether the question is worth asking at all. The audit regularly concludes that a conventional script solves the problem for a fraction of the price, which is a successful audit, not a wasted one. If the MVP clears its pass mark, production starts from €50,000.

Frequently asked questions

How long should a proof of concept take?

Two to six weeks, with the shorter end for pure feasibility questions and the longer end when real data has to be prepared first.

  • If it runs longer than six weeks it has usually stopped being a PoC and become an unbudgeted pilot.
  • Most of the elapsed time goes to data access and cleaning, not modelling. Plan for that.
  • Fix the end date before starting, and write down what result would justify continuing.

What is the difference between a proof of concept and a prototype?

A PoC tests feasibility; a prototype tests design. A PoC can be ugly, hard-coded and unusable by anyone but its author, because its only job is to answer a technical question.

  • A prototype is usually about the interface and the workflow: whether the thing makes sense to a user.
  • You can need both, in either order, depending on whether your risk is technical or human.
  • Neither should be extended into production code. Rewriting is less expensive than untangling a PoC that was never designed to be maintained.

Who should be involved in a proof of concept?

Fewer people than you would expect, and one you might not have considered: whoever controls access to the data.

  • Data access is the most common cause of a PoC stalling, and it is an organisational problem, not a technical one.
  • One engineer and one domain expert is usually the right size. Larger groups slow the loop without improving the answer.
  • Keep the eventual daily user informed but not embedded, their moment is the pilot, where fit is the question.
Go deeper with Crux Digits

Want this applied in your business? See how we take it to production:

← All AI terms

From concept to working tool?

We build this AI in production, at fixed prices, with one named expert. Start with a free consultation.

Book a free consultation →