Talk to us about your proof of concept.
A no-obligation introductory call of half an hour. Tell us which assumption you want to test: we will help you sharpen the question and give direction on what a PoC would deliver for you.
Service · Web development
Proof of concept (PoC) development.
A small, rapid prototype that validates one technical assumption before you make a major investment. Cheaper than an MVP, more focused than a pilot. For IT decisions where the answer to "can this actually be done?" must first be firmly substantiated.
What is a proof of concept?
A proof of concept (PoC) is a lean prototype that tests one specific assumption: can we integrate this data, does this model learn from our data, does this platform deliver the performance we need at our volume? The aim isn't to deliver a working product; it's to show with the least possible investment that the idea works technically before more money is committed. A PoC is therefore an investment in risk reduction, not in an end product.
This is what fundamentally sets a PoC apart from an MVP or a pilot. An MVP is the smallest version of a product that lets real users experience it, so it is about market and user validation. A pilot tests whether something scales in a realistic production environment with real customers or operational conditions. A PoC, by contrast, answers the bare engineering question: "can this be done?" and nothing more. For many decisions about digital transformation, AI adoption or vendor selection, that is exactly the signal missing before a board decision can be made responsibly.
Dutch mid-market and enterprise organisations are full of major IT decisions taken on instinct, because there was no time or appetite to first check rigorously whether the idea holds up technically. Every year, millions are lost on projects that looked perfect on paper but foundered on an assumption no one had tested. A well-scoped PoC costs a fraction of that and gives your steering committee something concrete to work with.
We have been building PoCs for years for organisations facing such major IT choices: a vendor comparison, an AI ambition, a legacy migration, an architecture decision. The page below explains exactly what we deliver, when a PoC is truly worthwhile, and what we deliberately do not do in a PoC engagement.
Three types of proof of concept.
Most PoC questions fall into one of these three categories. In the introductory call, we advise which type suits your challenge. Sometimes the answer emerges within an hour at a whiteboard without anything needing to be built.
Technical PoC
For when the question is purely engineering. Does this sensor work in our factory environment? Can we connect System X to Y without the lead time going off track? Does our architecture reach the required throughput under realistic load? At the end you have a working test setup with measurements, not a presentation. It runs reproducibly, with the scripts and configuration included, so your own team can verify it or take it further.
IntegrationPerformanceHardware/IoTArchitecture
AI/ML proof of concept
For questions such as "does a model learn patterns from OUR data?" We train on a sample of your own data, validate against an honest baseline (often a simple rule-based approach or the existing process), and report accuracy, false-positive rate, and the assumptions we had to make to get there. No demo with cherry-picked examples: a substantiated yes, no, or "yes, provided that": label quality in order, data volume X, retraining cadence Y.
Model feasibilityData qualityBaseline comparisonBias check
Vendor or platform comparison
You are torn between Snowflake and Databricks, Microsoft Fabric or native AWS, your own API gateway or Kong. We run a comparable workload on both platforms, execute the same scenarios, and deliver a matrix of cost, performance and operational findings, including what you only learn by actually running it rather than from the documentation or a vendor deck. Intended as decision input for a board, a procurement process, or an internal architecture choice.
Side-by-sideTCO indicationOperational fitLock-in analysis
What you get at the end.
A PoC is only valuable if it delivers usable evidence for a board, steering committee or architecture review board. Our standard package therefore always includes both the working artefact and the explanation around it.
- A working PoC demoReal code or a real test setup, not a Figma mock-up or slide deck. Reproducible to run, with instructions.
- Documentation of lessons learnedWhat worked, what didn't, and why. Including the assumptions we had to make explicit and the risks we uncovered along the way.
- A clear recommendationProceed, stop or adjust, with supporting rationale. An honest "stop" is just as valuable to us as a "proceed": you have saved the cost of a failed large project.
- Code and configuration as the basis for the next stepThe PoC code is not disposable. Relevant parts can be reused as a starting point for an MVP or production version.
- An indication of follow-on investmentA first estimate of the effort an MVP or production implementation would roughly require, based on what the PoC has shown.
- A working session with your teamAt the end, we go through the findings together with your architects, product owner and, if relevant, a stakeholder from the business, so the conclusions really land where the decision is made.
When a PoC makes sense.
Not every software question calls for a PoC. But in these patterns, a few weeks of preliminary investigation often saves far more in avoided risk or cost.
AI & ML
Model feasibility on your own data
You are considering predictive models, anomaly detection or NLP on your own dataset, but don't know whether the data contains a signal. A PoC trains on a sample and gives an honest answer, including what still needs to be done about data quality.
Integration
Integration with legacy or vendor systems
You don't know whether a specific system can be connected without compromising stability. Especially relevant when replacing legacy software and when integrating with SaaS vendors that lack a mature API.
Performance
Will it scale at our volume
A vendor claims their platform can handle 10k transactions per second. On paper. A PoC tells you whether it also holds up at your data volumes, queries and peak patterns, and what the operational costs would be.
Vendor selection
Build vs buy, or vendor A vs B
Choosing between two platforms can be a PoC question. Also read our article on the build vs buy decision. Sometimes a short PoC shows that a standard package is good enough after all.
Architecture
Microservices, event-driven or a monolith after all
Architectural choices are expensive to reverse. A PoC with a realistic slice can validate whether a pattern works for your team size, deployment frequency and use case.
Migration
Cloud migration or replatforming
The question is rarely "can this go to the cloud?" but "can this workload move without downtime, while maintaining compliance, at an acceptable cost?" A PoC with an isolated part of the landscape gives a concrete answer.
Hardware & IoT
Sensors or edge hardware in your environment
Spec sheets always sound great. Only when the sensor or edge device is actually in your factory, vehicle or installation do you know whether the signal is stable, whether connectivity remains acceptable, and which faults you will encounter in practice.
Compliance
Privacy or regulatory aspects
Sometimes the question is whether an idea is even permissible under GDPR, the EU AI Act or sector-specific regulation. A short PoC, linked to a privacy or compliance check, can prevent you from hitting an insurmountable legal obstacle after months of development.
Not yet sure about a large project?
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →How a PoC engagement works.
1
Introduction and sharpening the question
A conversation to distil the assumption you actually want to test. Often this is already half the value: a well-framed PoC question is far sharper than "can we do something with this?". Sometimes an hour in, it turns out a PoC isn't needed at all because the answer is already known from the literature or existing implementations.
2
Scope document and success criteria
We record: which assumption we are testing, which measures will tell us whether it succeeds, and which data or access we need from your team. This is deliberately brief, as a PoC almost always derails because the scope expands, not because of technical problems.
3
Building in a few short sprints
Lean engineering: the least code needed to answer the question, no polish, no "let's make it production-ready straight away". A weekly check-in with your architect or product owner ensures surprises surface early.
4
Evaluation and recommendation
We present the findings to your team. Not just "it works" or "it doesn't work", but also the assumptions underpinning them, the risks identified, and the estimated effort for a next step. In writing and verbally, so the decision-making discussion that follows can be conducted sharply.
What we deliberately do *not* do in a PoC.
A PoC is only valuable if it stays small. These are the matters we explicitly keep out of scope: not out of laziness, but because they would turn the PoC into something else.
Out of scope
Production-grade security
A PoC receives basic security but not full hardening, a penetration test, or SOC 2-level compliance. That belongs to the MVP or production version where real users enter real data, not to a test set-up in a sandboxed lab.
Out of scope
Scalability well beyond test volumes
We validate whether it works under a realistic workload, not under the peak loads of a fully mature implementation. Skipping this is deliberate, otherwise you end up building a mini production platform under the label of a PoC.
Out of scope
Full UX or design
A PoC has just enough interface to test the assumption. No design system, no branding work, no UX research with end users. That moves to the MVP phase, where interaction is part of the question.
Out of scope
End-user documentation
The PoC receives technical documentation for architects and your IT team, not manuals for business users. If the PoC succeeds and you move on to an MVP, end-user documentation is produced in that phase.
Out of scope
Operations and SLA
A PoC runs in a staging or sandbox environment without an SLA. No 24/7 monitoring, no incident response, no production-grade backup strategy. That would cost many times the PoC investment and add nothing to the decision-making input.
Out of scope
Full integration breadth
We integrate only the minimum set of systems needed to answer the question, not your entire application landscape at once. An integration PoC that tries to connect "everything with everything" is no longer a PoC.
Frequently asked questions.
The questions we usually receive in the first PoC conversation.
What is the difference between a PoC, an MVP and a pilot?
A PoC (proof of concept) tests "can it be done?", purely technical feasibility. An MVP (minimum viable product) tests "do people want it?", the smallest working version of a product you dare to show real users. A pilot tests "does it scale?", a limited production implementation with a defined group of customers or locations. The three often follow one another, but sometimes skip stages: for a purely infrastructural decision, a PoC may be enough without ever building an MVP.
When does a PoC make sense and when doesn't it?
A PoC makes sense when there is a concrete uncertainty you cannot resolve through desk research or a conversation with an architect. This is especially true for AI models on your own data, performance at high volumes, integration with legacy systems, and vendor choices. A PoC does not make sense when the uncertainty is commercial rather than technical (in which case an MVP is more appropriate), when the problem has already been demonstrably solved elsewhere, or when the scope grows so broad that it effectively becomes an MVP.
What if the PoC fails — is that wasted money?
A failed PoC is actually one of the most valuable outcomes: for a fraction of the cost of a failed large project, you have learned that a direction does not work, often including the specific reasons why. We have clients who have avoided tens of thousands of euros in unnecessary investment because a PoC returned a "no". That is why we report failure just as carefully as success, including what would be needed to make it possible after all.
What determines the cost of a PoC?
Three things: how sharply the question is defined at the start, how accessible the data or systems needed for the test are, and how deep the validation needs to go. An AI feasibility PoC on clean data is far lighter than a PoC that first requires unlocking data from three legacy systems. After the initial conversation we provide a substantiated estimate and keep the sprint budget tightly controlled, because a PoC that overruns is rarely still a PoC.
How long does a PoC engagement take?
A well-scoped PoC is an engagement of a limited number of sprints, deliberately kept short. The aim is for you to quickly have a substantiated answer for your decision-making, not for us to deliver a polished product. If the scope turns out to be too large, we would rather split it into two smaller PoCs or move on to an MVP engagement.
What do you explicitly NOT do in a PoC?
No production-grade security and compliance (that belongs to an MVP or production phase). No full UX or design, only what is needed to answer the question. No end-user documentation. No operations or SLA. No scalability optimisation far beyond the test volume. That may sound like a lot of "nots", but that is precisely why a PoC is a PoC: by deliberately leaving these things out, we keep the engagement small and focused.
Who are typical clients for a PoC?
CTOs, CIOs and innovation managers in mid-market and enterprise organisations. Business units that need to justify an investment to a board and don't want to arrive empty-handed. Organisations facing a major decision such as enterprise software development, an ERP replacement, or a first serious step into AI. Also IT departments that want to explore internally whether an idea from the business is technically feasible before committing.
What happens after a successful PoC?
Usually an MVP or a direct production implementation, depending on what the PoC has shown. We can take on that next step, but you are under no obligation: the PoC code and documentation are yours, and you can also have your own team or another party take them forward. Our final report includes indicative effort and points to watch for the next phase. Also read our knowledge base article on what custom software costs if you are exploring the broader pricing picture.