Know whether your product idea is viable before building it

You have been walking around with an idea for a while. An app for your customers, a device that takes a measurement now done by hand, a portal your whole industry could use. You have talked to a few people about it and they liked it. But between "like it" and "we are going to build it" there is a gap, and money disappears into that gap. In a few weeks we look at whether the idea is technically possible, whether anyone is waiting for it, and what it will roughly cost. Then you decide.

Why you test first and only then build

Most products do not fail because they are badly built. They fail because nobody had the problem they solve, or because the technology turned out three times more expensive than expected. You usually only run into that when the first version is finished and the invoice is paid. A feasibility study moves that discovery to the beginning, where it is still cheap.

It is not a thick advisory report and not a forty-page business plan. It is a short, focused test of the three things that can break a product idea. We do it with the same people who would build it later, so the technical estimate does not come from a consultant who then throws it over the fence.

Three questions: can it be done, does anyone want it, and what does it cost

Can it be done is the technical question. Does the sensor you need exist, or does it have to be made? Does the vendor of your accounting package offer an API you can connect to? Is the language model you have in mind reliable enough for your application, or only in the demo? We find that out, and where it can be done quickly we build a small piece to know for sure. Sometimes an afternoon of trying is worth more than a week of reading.

Does anyone want it is the market question. We talk to a handful of people from your target group, preferably people you do not know yet. Not to ask whether they like the idea, because almost everyone says yes to that. But to hear how they solve the problem now, what that costs them, and whether they want to change anything about it. What does it cost is the math: what it takes to build, what it costs per month to run, and what is needed in maintenance, certification, or hardware. A rough estimate, not a proposal, but honest enough to decide on.

What you have in your hands after two to three weeks

A short report, deliberately short. One page on which the idea is sharply described, because that page often turns out to be half the work. The technical check with the biggest risks and how we would tackle them. A summary of the conversations, verbatim where possible. The cost estimate. And a recommendation in three flavors: go ahead, adjust, or stop.

Adjust is the most common. The idea holds, but the first version has to be smaller, the target group is a different one than you thought, or an existing package already does eighty percent and you only have to build the last twenty. If it is really not feasible, we say that too. Better now than after a year of building. The report is yours, even if you decide to carry on with another party.

From feasible to the first prototype

If the answer is yes, you do not have to start over. The page with the idea, the technical check, and the conversations are exactly the input the Prototype in 10 business days needs. Within two weeks you then have something that works, on real data, that your target group can click through. After that it can grow through MVP development into a version you show to real customers, and where it concerns a physical product we help with the step Prototype to production.

Everything starts with a free intake. You tell us what you have in mind, we tell you whether a feasibility study makes sense or whether you are better off having a prototype built right away. That too is an answer you would rather hear up front.