You've got an idea. A piece of software that would solve a real problem in your business, automate something painful, integrate two systems that don't talk to each other, build a portal your customers have been asking for. On paper, it makes complete sense.
But you're not entirely sure it will work the way you're imagining. The integration might be more complicated than the vendor's docs suggest. The AI might not be accurate enough for your real data. The whole approach might break down when it hits the messy reality of your existing systems.
So you have a choice. Commit the full budget and hope it works. Spend months in workshops and analysis that produce documents but no working code. Or do something we genuinely believe is the smartest move available: spend two weeks finding out.
That's what a proof of concept is. And it might be the most useful thing you do this year.
What you actually get from a POC
In two weeks, working software that answers one specific question: will this idea hold up under real conditions?
Not a polished product. Not a 40-page strategy document. Not a Figma mockup. Actual code, running against actual data, telling you whether the riskiest part of your project is going to work.
Concretely, you walk away with:
Working code that proves (or disproves) the technical core of your idea
Measured results, accuracy figures, performance numbers, integration test outcomes
A short, honest write-up of what we learned, what worked, what surprised us, and what it means for the full project
A clear recommendation on whether to proceed, adjust the scope, or walk away
That last point matters. If the POC shows the idea doesn't work the way you hoped, we'll tell you. We'd rather give you that answer in week two than build a project around an assumption that breaks in month six.
Why two weeks (and not two months)
Most "discovery phases" in our industry take far too long. Multi-week workshops. Stakeholder interviews. Strategy documents nobody reads. They produce paperwork instead of evidence, and they cost real money while delaying the actual decision.
Our POCs work differently. They're deliberately short, focused, and pragmatic:
- One clear question to answer (not five)
- One or two developers working on it (not a team)
- One to two weeks from start to finish (not one to two months)
- A working result instead of a slide deck
The reason this works is that most software risks live in one or two specific places, usually an integration, an algorithm, or a data assumption. You don't need to validate the whole project. You need to test the parts that would kill it.
A focused POC catches those killers fast. That's the entire point.
What kinds of ideas benefit most from a POC
We get asked about POCs across a wide range of projects. The ones where they consistently pay off:
You want to integrate with an external system you don't fully understand.
An ERP, a legacy database, a third-party API, a piece of hardware. The documentation looks promising, but you suspect the real implementation will be messier. We connect to the real thing and find out, before you've built half a product around assumptions that might not hold.
You're betting on AI accuracy.
AI is impressive in demos and inconsistent in production. If your project depends on the AI getting things right at a certain rate, extracting fields from invoices, classifying support tickets, summarising documents, we test it on your actual data and give you measured accuracy numbers. Not vendor promises. Real percentages on real samples.
You're not sure your data can support the idea.
Your data lives across systems, isn't standardised, or hasn't been touched in years. Before you build software that depends on that data, a POC tells you what shape it's actually in and what cleanup the real project will require.
You're considering an unusual architecture.
Something headless, real-time, multi-tenant, edge-deployed, or otherwise outside the standard pattern. A POC lets us prove the architecture works in your specific context before committing to it for the full build.
You need to convince internal stakeholders.
Sometimes the project is technically sound but politically uncertain. A working POC, showing the core idea actually functioning, is far more persuasive than any pitch deck. We've seen POCs unlock budgets that pitches couldn't.
How a POC at Vulpo actually works
The process is intentionally simple:
1. A first conversation.
We sit down with you, physically or remotely, and figure out what your idea actually is, where the uncertainty lives, and what would need to be true for the project to succeed. This usually takes one meeting. No deck required.
2. We write down the question.
Together, we agree on the one or two specific things the POC needs to prove or disprove. Concrete and falsifiable. "Can we extract these five fields from this type of document with at least 90% accuracy?", not "explore AI possibilities."
3. We give you a fixed price and timeline.
A two-week POC has a clear scope, a clear deliverable, and a clear cost. No open-ended hourly billing. You know exactly what you're signing up for before we start.
4. We build it.
Quick stack choice, no infrastructure ceremony, no UI polish. Working code that answers the question. We work in the open, you can check in any time during the two weeks.
5. You get a clear answer.
At the end, a working demo, the measured results, an honest write-up, and a recommendation. You decide what happens next: commission the full build, adjust the scope, or walk away. All three are legitimate outcomes.
If you decide to proceed with the full project, the knowledge from the POC carries directly into the build, better architecture decisions, more accurate estimates, fewer surprises.
The cost question, answered honestly
A two-week POC costs a few thousand euros. The full project it might save you from costs tens of thousands or more.
If the POC confirms your idea is solid, you've spent a small amount to start the full project with confidence and concrete knowledge. Worth it.
If the POC reveals a fatal problem with the approach, you've spent a small amount to avoid spending much more on a project that wouldn't have worked. Even more worth it.
There's almost no scenario in which the POC is the expensive part of the story. It's the cheap insurance against the expensive scenarios.
When you probably don't need a POC
To be fair, not every project needs one. We'll tell you upfront if a POC won't add value. You can usually skip it when:
The project uses well-understood technology in a standard configuration
The integrations and data sources are well-documented and predictable
You've built something very similar before and know how the pieces fit
The total budget is small enough that being wrong is cheap
In those cases, we go straight to building. POCs earn their keep when there's genuine uncertainty, not when the path is already clear.
Ready to test your idea?
If you've been carrying around a software idea but aren't sure whether it would actually work, or if you've been quoted a large project budget and want to validate the riskiest assumptions before committing, a POC is almost certainly the right next step.
Tell us about your idea. In a single conversation, we can usually identify whether a POC would help, what it would need to prove, and what it would cost. No pressure to commit, no slide deck required.
Request your POC
