News

Proof of Concept: Process, Criteria, Limits

08 October 2026 · DigifyNow

Auf Deutsch lesen

A proof of concept tests exactly one technical question. For example: can AI reliably read our delivery notes? Or does our ERP's API return the data we need? Before you start, you set a measurable success criterion, a fixed timebox (usually two to four weeks) and real test data. At the end you decide whether the project goes ahead, gets changed or stops. You don't get a finished product, and the code is usually thrown away.

What is a proof of concept, and what isn't it?

A proof of concept (PoC) is a small, time-boxed experiment that shows whether an idea can work technically at all. The Technology Readiness Level (TRL) scale shows where it fits. The EU uses this scale in its research programs, among other places, and there TRL 3 is explicitly called "experimental proof of concept." That is an early stage. The core function has been shown to work, but not yet in the real operating environment. A product in everyday use doesn't reach TRL 9 until much later. For executives, this means a PoC tells you whether something is technically possible. It does not tell you whether your employees will use it, whether it pays for itself or whether it runs reliably day to day. That's why at DigifyNow every PoC starts with one sentence in the form "We want to find out whether …" If two of these sentences can't be separated, you need two PoCs. A PoC has no user management, no polished design and no operations. If that's what you expect, what you really want is a prototype or an MVP.

When is a proof of concept worth it, and when isn't it?

A PoC is worth it when a technical risk could sink the whole project and you can settle that risk cheaply before the real budget is spent. Typical cases are a legacy system with no documented interface, an AI that needs to process free text or scanned documents, and a real-time connection to machines or point-of-sale systems. In our project work, though, a PoC often isn't worth it, and in these cases we say so and advise against one:

• The technology is standard, such as a CRM back office with forms, lists and user roles. The only open question is whether the workflow fits, and a prototype answers that.
• The real question is about the business or the organization: who maintains the data, and who signs off? That calls for a process analysis, not code.
• The decision has already been made. A PoC whose result nobody takes seriously is just expensive busywork.
• There's no real test data. A PoC built on made-up examples proves almost nothing.
• The interface vendor commits to the feature in writing and documents it. Then a look at the API documentation is often enough.

Whether the workflow is clear enough in the first place usually comes out faster in a process analysis with a template and example than in any test code.

How does a proof of concept work at DigifyNow?

DigifyNow sets up a PoC in five steps. All parameters are put in writing before any code is written, so the result is judged against agreed criteria and not by gut feeling later on:

1. Define the test question: exactly one question that can be answered yes or no, such as "Can we read orders from our existing ERP through its API?"
2. Set the success criterion: a measurable threshold, such as a share of real documents, agreed in advance, that must be captured correctly without manual correction. You set the threshold, not us, because only you know how much rework your process can absorb.
3. Provide test data: real data, pseudonymized wherever possible, in enough volume to cover the full range of everyday cases, including the messy ones.
4. Set the timebox: usually two to four weeks with a fixed end date. When time is up, the results are evaluated, even if they're incomplete.
5. Document the decision: go ahead, change course or stop. This includes a short note on what was learned and which risks are still open.

What you get is not a demo screen but a finding, often a script, a test log and a one-page write-up. If the finding is positive, the next steps are concept, sprints and acceptance. Our article on how a software project runs walks through them.

What does a proof of concept look like for an AI project?

With AI, the PoC matters even more because language models are not deterministic. The same input can produce different outputs, so one successful run in a demo proves very little. That's why DigifyNow tests AI projects against a fixed test set: a collection of real cases from your business, such as emails, quotes or delivery notes, each paired with the correct result. Every version of the prompt and every choice of model runs against the same set. That way you can see whether a change actually improves things or just fixes one case while breaking two others. We measure what matters for the workflow: how many cases are correct, how many need rework, and how many are wrong without anyone noticing. That last group is the most dangerous. As soon as personal data goes to an external AI service, the GDPR sets requirements for the contract with that provider. Check with your data protection officer whether that contract is in place and sufficient before the first real record leaves your company. If the test succeeds, our article on how to roll out an AI assistant in your company covers what comes next.

Request a free assessment of your project