PoC Sprint
First a prototype that actually runs. Then the decision.
You have an idea and want to know whether it holds up before you put money into building it. We build a prototype with your real or realistic data, show it to your team and tell you whether the build is worth it. No slide deck, no concept paper.
- For whom
- For teams with an idea that still needs to prove itself.
- Duration
- Days to two weeks
- Outcome
- Running prototype, demo, architecture note, build plan
A clear question, access to data and someone who decides.
We pin down the question in a call, or it comes out of an audit. Real data works best. If that's not possible, we build with test data in the same structure.
What we need
- One question the PoC should answer
- Access to real or realistic data
- One contact who makes the subject-matter decisions
- A test environment on your side, or ours, hosted in the EU
Ten working days, one decision.
This is how a PoC sprint typically runs. In shorter sprints we combine steps, and the order stays the same.
Day 1
Sharpen the question
Kickoff with the person who decides. Afterwards the question and success criterion are written down.
Day 2
Connect the data
Access to real or realistic data, a first sample, first surprises.
Day 3
First end-to-end run
One case runs through completely once. Not pretty yet, but real.
Days 4 to 6
Build what matters
Exactly what answers the question. Nothing that only looks good.
Day 7
Checkpoint
Demo with your team. Corrections happen now, not at the end.
Days 8 and 9
Test with real cases
Edge cases, error rates, effort. What doesn't hold up gets written down.
Day 10
Present the result
Live demo, architecture note, build plan and a clear recommendation.
Typical flow. In the first call we tailor each sprint to your question.
Days you see the current state
What you get at the end.
A PoC isn't a finished product. It answers one question: is the build worth it? Everything is documented and reproducible. What's missing for day-to-day operation comes in the product build.
Running prototype
Does only what's needed, but really does it. You can run it yourself, and the code is yours.
Demo with your team
Live with your data. We write down questions, open points and next steps.
Architecture note
How the parts fit together, which interfaces exist and why we decided what we did. Written so your team can work with it.
Build plan
What the finished product needs: timeline, effort, integrations, risks. The basis for the product build offer.
If the build isn't worth it, we say so.
A PoC can also show that the data isn't good enough, the effort outweighs the benefit, or off-the-shelf software fits better. Then that's exactly what the note says. You know where you stand, and we don't get a follow-up project. We're fine with that.
Common questions
How fast can we start?
Usually one to two weeks after the call. A first running version is often there after a few days.
Do we need an audit first?
No, you can start right away. If the question is still fuzzy, we take half a day at the start to sharpen it.
Do we get the code?
Yes. Usage rights pass to you on payment. You can develop the PoC further yourself, continue with another team or use it as the basis for a tender.
What happens after the PoC?
That's your call: product build with us, continue in-house, or stop. The architecture note is written so any team can work with it.
From PoC to product.
After the PoC you have a running prototype, an architecture note and a build plan. If you like, we turn that into an offer for the product build.
- Product BuildFrom design to operations, in weeks rather than quarters
- Fractional CTOIf your team keeps building and wants experienced support
If the PoC shows the build isn't worth it, the note says so. You're under no obligation to order anything after that.
Which idea do you want to test?
Send us the question the PoC should answer. We'll get back to you with a proposal.
On working days we usually reply within 24 hours.