Zero to One
Zero to one is the move from an idea written on a document to a real product, downloadable or usable by real people. It is the moment when technical decisions carry the most weight and the information available is thin. Here is the method I use as a fractional CTO to take a startup from this point to a first product in users' hands, with BRUM as concrete proof.
What I mean by "zero to one"
Zero to one is not the validation stage with a form or a no-code prototype: that comes earlier. It is the next step, once the idea already has a direction and it is time to build the first real product, one that can hold up under real users and collect real signal, not just stated interest. It is the stage where the wrong stack or an architecture built for the wrong scale cost more than anywhere else, because the runway to fix them is short.
The method: one question to validate, not a feature list
The starting point is not a list of features, it is one clear question the first product has to answer. Everything that does not help answer that question waits for version two. It is a discipline more than a technique: saying no to features that sound reasonable in the abstract but are not needed to validate the main hypothesis, to get something honest, even if bare-bones, in front of users as soon as possible.
The proof: BRUM, from concept to 150,000 downloads
As CTO of BRUM Patenti, I took the product from concept to a first MVP in store in two months, then iterated continuously listening to real users. Today the platform counts 150,000 downloads, a 4.5★ rating, and 50,000 active users a month: numbers that did not exist at launch, built iteration after iteration on top of a first release designed to learn from, not to be perfect.
Stack and architecture: reversible choices, not imaginary scale
In the zero-to-one stage the most common temptation is designing for a scale the product does not have yet. The technical choices of the first months should be judged by the speed they allow, not by how much load they could handle in a future that might never arrive: a simple architecture you can refactor later beats a complex one built for an uncertain future. The few genuinely hard-to-reverse decisions deserve care; everything else can stay deliberately simple.
After the MVP: a roadmap that holds up, not a wishlist
The first release is not the finish line: it is the point from which you start deciding what to build next, with real data instead of assumptions. That is the move from zero to one into an actual product roadmap, with reasoned priorities and a short horizon. I go into more detail on the dedicated product roadmap page.
How a "zero to one" engagement with me works
I work inside the team, a day and a half a week, with written milestones every 30 days. The initial contract is 3 months with monthly renewal, at a fixed fee, not hourly: a typical engagement at this stage lasts between 4 and 8 months, the time it takes to bring the product from zero to a solid first version and the team to walk on its own.
Frequently asked questions
What does "zero to one" mean for a startup?
It is the move from an idea that already has a clear direction to a first real product in users' hands: not the initial validation stage, but the one where you actually build, where technical decisions carry the most weight.
How long does it take to get to an MVP in store?
It depends on the product, but it is possible to do it quickly with the right scope: with BRUM it took two months from concept to a first MVP in store, by narrowing the first version down to a single question to validate.
Do I need a technical cofounder or is a fractional CTO enough for this stage?
A fractional CTO covers the same decisions a technical cofounder would: stack, architecture, priorities, without equity and without a permanent commitment. Useful especially when it is not yet clear whether the fit for a cofounder truly exists.
What do I need before starting the zero-to-one stage?
A direction that is already validated, even informally: an idea with a clear target and a first hypothesis about who would use it. If that is missing too, the step before this one is validation, not yet building.
Do you still write code at this stage?
Yes, when it is needed to unblock the first release or to make architectural decisions hands-on, on top of leading stack, scope and priorities.