What should a software proof of concept prove?

The demo goes brilliantly. The stakeholders are excited, the developer is confident, and the board approves the budget. Six months and €80,000 later, the full system is in crisis — not because the core idea was wrong, but because the proof of concept never tested anything that actually mattered in production. It proved the idea was clever. It didn't prove the idea would work.

This article will help you define what a PoC must validate, set clear success criteria before you commission one, and judge — honestly — whether a PoC result genuinely reduces your investment risk or just creates momentum.

Why do so many PoCs feel like success but lead to failure?

A proof of concept is supposed to answer a specific question about uncertainty. The problem is that most PoCs answer the easy question — "can this thing be built at all?" — instead of the hard ones: "will it perform under real load?", "will it survive our integration landscape?", or "will the people who have to use it every day actually use it?"

The result is a demo that works perfectly on a developer's laptop, with twelve records, no live API connections, and a single test user who already understands the system. That PoC did prove something. Just not the things that determine whether the project succeeds.

What is the actual purpose of a proof of concept?

A PoC is a structured experiment designed to reduce the most dangerous uncertainties in a project before you commit to a full build. The key word is dangerous. Not every uncertainty needs a PoC — only the ones that, if unresolved, could cause the entire investment to fail.

That means before you design a single screen or write a single line of code, you need to ask: what are the top three things that could cause this project to collapse? Your PoC should test exactly those things.

Common high-risk uncertainties that PoCs routinely ignore:

• Scalability: The demo runs fine with sample data. What happens when 50,000 orders are processed and 30 users are logged in simultaneously?
• Integration with existing systems: The PoC used mock data. What happens when the real Exact Online API, the real WMS, and the real customer portal have to talk to each other — with their actual rate limits, authentication flows, and data inconsistencies?
• Data migration: The PoC started from scratch. But the live system needs to absorb ten years of legacy data, some of it inconsistent and some of it in formats that haven't been touched since 2014.
• Security and access control: The PoC had one admin account. The real system needs role-based permissions, audit logging, and compliance with GDPR or ISO 27001.
• Business process fit: The PoC followed the "happy path" — a clean, linear workflow. Real users have exceptions, edge cases, and workarounds baked into how they actually work.
• User adoption: The PoC was tested by the person who commissioned it. The people who will use it daily weren't involved.

How do you define PoC success criteria before you start?

This is where most projects skip a critical step. Success criteria should be written down, agreed upon, and treated as a contract — before a single prototype is built. If you can't write them down, your PoC has no defined purpose.

A useful success criterion follows this pattern: "The PoC will be considered successful if [specific outcome] is demonstrated under [specific conditions] and [specific constraint] is not exceeded."

For example:

• ✅ "The PoC is successful if a purchase order created in FileMaker is synced to Exact Online within 30 seconds, under a load of 200 simultaneous transactions, with zero manual intervention."
• ✅ "The PoC is successful if three warehouse staff — who have not been trained in advance — can complete a pick-and-pack workflow without assistance within 10 minutes."
• ❌ "The PoC is successful if the demo looks good and the client is happy."

Notice the difference. The first two criteria are falsifiable. They either pass or fail based on observable, measurable evidence. The third one is a feeling — and feelings are how you end up approving a project that shouldn't be approved.

What are the right risks to test first?

Not every risk deserves a PoC. Use this prioritisation logic:

1. Novel technical risk: Has your team actually done this before? If you're connecting to a new API, building on an unfamiliar platform, or implementing a process that nobody in the team has delivered end-to-end — that's a PoC candidate.
2. High-impact assumption: What are you assuming is true that, if false, changes everything? For instance: "We're assuming Exact Online's API supports bulk upserts." Test that assumption. It might not be true in the way you expect.
3. User behaviour assumption: "We're assuming finance staff will adopt the new approval workflow." Don't assume. Run a structured user test with real staff.
4. Integration dependency: Any integration with a third-party system that your team hasn't personally connected before is a risk. APIs have undocumented quirks, rate limits, and authentication behaviours that only surface when you actually build the connection.
5. Data quality risk: If migration from a legacy system is required, the data quality risk is almost always underestimated. Sample your actual data early. You will find surprises.

What should a PoC explicitly not try to prove?

This is as important as knowing what to test. A PoC is not a prototype of the full system. It is not a minimum viable product. It is not a sales demo. Scope creep into any of these categories is a signal that the PoC has lost its purpose.

A PoC should not:

• Build the full user interface (unless UI/UX adoption is the specific risk being tested)
• Cover every edge case or business rule
• Be production-ready code (it will almost certainly be thrown away — and that's fine)
• Last longer than 2–4 weeks (if it takes longer, you're building a product, not an experiment)

The moment a PoC starts growing features to "impress stakeholders" or "cover all the scenarios," it has stopped being a risk-reduction exercise and become a political artefact. Recognise that moment and pull it back.

How do you evaluate whether a PoC result actually de-risks your decision?

Once a PoC is complete, run it through this evaluation before approving the full build:

PoC Evaluation Checklist

• Were the success criteria written down before the PoC started? (If no, you are evaluating a demo, not an experiment.)
• Did the PoC test the riskiest assumptions — not just the easiest ones to demonstrate?
• Were the tests run under realistic conditions (real data volumes, real integrations, real users)?
• Did real end-users — not just the project team — interact with the PoC?
• Are there clear pass/fail results against each criterion, with evidence?
• Have any new risks surfaced during the PoC that now need to be addressed in the full build?
• Does the team have a realistic estimate of full-build effort informed by what the PoC revealed — not the estimate made before it?
• Is there explicit documentation of what the PoC did not test, and a plan for how those gaps will be addressed?

If you can't check most of these boxes, the PoC has not done its job. That is not automatically a reason to stop the project — but it is a reason to go back and run the experiment properly, or to consciously accept the risk you're carrying.

A concrete example: what this looks like in practice

A mid-sized logistics company wants to replace a manual dispatch process with a custom application connected to their transport management system and their customer portal. The initial instinct is to build a prototype showing the new dispatch screen.

Instead, they identify the three highest risks:

1. The transport management system's API has never been integrated with anything before — the documentation is thin.
2. Dispatch staff have used a paper-based process for 12 years. Adoption is genuinely uncertain.
3. Order volumes during peak periods are 10× normal — performance under load is unknown.

They commission a focused 3-week PoC that:

• Connects to the real TMS API using real credentials and processes 500 real orders (not mock data)
• Runs a 90-minute observed session with four dispatch staff who were given no training in advance
• Runs a load test simulating peak-period volumes

The PoC reveals: the TMS API has a rate limit that would cause failures at peak volume, and two dispatch staff struggle significantly with the new workflow. Both findings change the architecture and the UX design of the full build — before a single euro of the main budget is spent.

That is what a PoC is supposed to do.

FAQ

How long should a PoC take? Typically 1–4 weeks. If it's taking longer, the scope has expanded beyond risk validation. A PoC that takes three months is a poorly scoped project, not a proof of concept.

Should we throw the PoC code away after? In most cases, yes — and plan for that from the start. PoC code is optimised for speed of learning, not for maintainability, security, or scalability. Trying to build production code on top of PoC code usually produces fragile systems. The value of the PoC is the knowledge, not the artefact.

What's the difference between a PoC, a prototype, and an MVP? A PoC answers: "can this work / does this assumption hold?" A prototype answers: "does this feel right to the user?" An MVP answers: "will real users engage with this product in production?" They serve different purposes at different stages. Conflating them is a common and expensive mistake.

Who should be involved in a PoC? At minimum: a technical lead who can build the experiment, at least one real end-user for any process or UX risk, and the decision-maker who will evaluate the result. The decision-maker must define the success criteria before the PoC starts — not assess the result after the fact.

What if the PoC fails? A PoC that fails is a success. It has just saved you from a failed full build. The correct response is: document what was learned, reassess the architecture or approach, and decide whether to run a revised experiment or change direction. A PoC failure that leads to a changed decision is one of the most valuable outcomes a project team can produce.

Can we skip the PoC if we've done something similar before? Sometimes, yes — but be honest about what "similar" means. If your team has built the exact same integration, with the exact same system, at the exact same data volume, the risk may genuinely be low. But if any of those three variables are new, there is probably at least one specific risk worth validating before you commit.

---

If you're facing a software investment decision — whether that's a custom FileMaker application, a web-based business tool, an API integration between systems, or an AI-assisted workflow — and you're unsure whether a PoC is warranted or how to structure one, Loggix can help you map the real risks before the budget is committed. That kind of early clarity is usually worth more than any demo.