The idea that looks promising on paper and that nobody has actually tried to build, tested before you bet a whole quarter on it
CODEPRESS's PoC builds only the part that puts a precise technical hypothesis to the test: four weeks, a fixed fee of €4,000 to €8,000. We measure performance, running costs and real limits, not an impression. By the end you have the working prototype, the code and a written report with the verdict, negative results included.
€4,000 – €8,0004 weeks · fixed price
What a proof of concept is for
There's a stretch before every big project where nobody in the company can say for certain whether the idea holds up: whether a complex integration responds fast enough, whether an algorithm scales past the toy case, and whether a third-party vendor behaves the way its documentation claims. Internal debate drags on for weeks, fed by opinions rather than measurements, while the actual project sits waiting for an answer nobody has verified yet.
Building the whole product to find out is the waste a PoC avoids: you isolate the one question that matters, build the minimum piece able to answer it, and measure instead of arguing. What comes out is not a demo built to impress, but a written verdict that stands even when it says the idea, as it is, doesn't hold up.
What a proof of concept covers
The question, defined before writing a line
Before we start we agree on what counts as an answer: which number, which threshold, or which observed behaviour would make the hypothesis true or false. Without that boundary written down in advance, any result could be read as a success.
Only the part that tests the hypothesis
We don't build the whole product or a polished interface: we isolate the technical piece that decides the question, whether that's an algorithm, an integration or a load to withstand, and leave out everything that would only exist to impress whoever is watching.
Real measurements, not estimates
The prototype runs against data and conditions close to the real ones, not a tame lab case: performance under load, running costs estimated from observed consumption, and the limits that only show up once something stops working as expected.
The verdict, written and unsoftened
At the end of the four weeks the verdict goes on paper exactly as the measurements produced it, including when it's negative: a prototype built to please whoever commissioned it is just time spent badly.
How a proof of concept works
Defining the question
Before writing any code we sit down with whoever in the company understands the problem and pin down the exact question and the threshold that separates a yes from a no: that's the step that turns the rest of the four weeks into engineering, not opinion.
Targeted build
We write only the part needed to answer the question: if it's about how an algorithm performs on a real volume of data, that's what we build, not an interface around it that nobody asked to see.
Measuring under real conditions
We bring the prototype into contact with data, load or external systems as close to the real thing as possible, and record what happens: where it holds, where it breaks, and what it costs to run.
Report and verdict
We write the verdict, the numbers behind it, and what reaching production would take, then talk it through with you before handing over the document.
What you get from a proof of concept
- The working prototype, ready for you to run and watch, not just read about in a document
- The source code written during the four weeks, yours from day one
- The starting question in writing, with the threshold separating a yes from a no agreed before work began
- The measurements collected: performance, running costs observed, and limits hit during testing
- The written verdict, including the case where the hypothesis doesn't hold up
- A read on what it would take, in time and in work, to bring the prototype to production
When a proof of concept is not for you
- Technical feasibility is already proven, maybe by an earlier PoC: at that point the right question is to build, not to measure again, and feature development is the right tool.
- The doubt you have isn't technical but commercial, for instance whether anyone would pay for the thing: four weeks of engineering can't answer a question only the market can answer.
- Four weeks isn't enough for the domain in question, for the regulatory complexity involved, or for the number of external systems it touches: that's something to say before signing, not to discover halfway through.
What a proof of concept costs, and why
Two things move the number between €4,000 and €8,000: the complexity of the technical question being tested, and how many external systems the prototype has to touch to produce a real measurement. An isolated algorithm tested against data you already have lands near the low end; a prototype that has to talk to several third-party services costs more, because every integration adds build work before you can measure anything.
The number is set the moment the question is: before that point there's no price, because there's no hypothesis yet to test. Once the threshold separating a yes from a no is written down, that figure holds, whatever the measurements say by the end of the four weeks.
Proof of concept: frequently asked questions
- How much does a proof of concept cost?
- The prototype costs €4,000 to €8,000, always fixed. What decides where the number lands inside that range is the complexity of the technical question and how many external systems the prototype has to touch to produce a real measurement. The price is set together with the question, before a line of code is written, and holds from that point on.
- How long does a PoC take?
- Four full weeks, from the question in writing to the verdict delivered: that's the duration set when the price is fixed, and it doesn't shift along the way, even if the prototype turns out trickier than it looked at the start. Inside that time sit the build of the part that answers the question, the measurements gathered under near-real conditions, and the final report.
- Does the PoC become the final product?
- No: the prototype is built to answer a specific question, not to carry the traffic or the upkeep of a real product. Its code can give you a starting point, but the final report already includes an estimate of what reaching production would take, because the next step is almost always its own project, not a straight extension of those four weeks.
- What do you deliver at the end of the four weeks?
- The working prototype, the source code and a written report with the verdict on the starting question: whether the hypothesis holds, what the measurements showed, and what limits turned up during testing. The report also carries an estimate of what taking the prototype to production would take, so the next decision starts from numbers, not impressions.
- What if the PoC shows the idea does not work?
- That's a success, not a failure: finding out in four weeks and for a fixed fee that an idea doesn't hold up costs a fraction of finding out in month nine of a project already under way, with a team hired and a budget spent. A negative verdict is written with the same care as a positive one, because avoiding the wrong spend is exactly the service you're buying.