Do you have an idea that has to exist before you can find out whether it works?
Some questions cannot be answered on paper. We take a concept to a deployed product that real users can be put in front of, and we keep the first version small enough to learn from.
The problem
The idea is usually clear; what is unclear is which parts of it matter. Teams either build everything at once and launch late with a product nobody has touched, or they build a prototype so thin that the feedback is about the prototype rather than the idea. Both waste the one resource that matters at this stage, which is a fast, honest answer.
How we approach it
We define the one question the first version must answer, then build only what is needed to answer it — but build it properly: real accounts, real data, deployed on infrastructure that will not embarrass you if the answer is yes. Everything else is cut or faked openly. We instrument the product so the answer comes from usage rather than opinions, and we plan the second version only after the first one has been used.
Worked example
A scheduling product, first version in nine weeks
A founder wanted to know whether small clinics would pay for a scheduling tool that handled their specific cancellation rules. Instead of the full product, we built the booking flow, the cancellation logic, and a payment page, and skipped reporting, staff management, and integrations entirely. Three clinics used it for real appointments within nine weeks. The cancellation rules turned out to be right; the payment step was wrong — clinics wanted to invoice monthly, not charge per booking — and finding that out cost a few weeks rather than a year. The second version was built around that.
What you get
- A written scope for the first version, with what was cut and why
- A deployed product with real accounts, real data, and usage instrumentation
- A short usage report after the first weeks, in plain language
- The codebase and infrastructure, documented and yours to continue with