"Zero to one" gets used a lot. Usually as marketing.
Here's what it actually means: you're building something that doesn't exist yet, for a problem that's real but not yet clearly defined, with requirements that will change as you learn more.
That sounds chaotic. It is, sometimes. But it's also the most honest description of what early-stage product work actually looks like.
The zero-to-one constraint
When there's nothing existing to reference, every decision is load-bearing. There's no established pattern to defer to. No "the way we've always done it."
This makes decision-making slower and harder. But it also means every decision is an opportunity to do it right — not just replicate something that happened to work in a different context.
What this means for research
Before writing a line of code, we spend time understanding the problem domain. Not just talking to potential users, but studying the existing systems, the workarounds people have built, the constraints of the environment.
This phase can feel unproductive. But the work done here determines whether the product has a foundation.
What this means for architecture
When you're building something new, you don't know yet what will be used heavily and what won't. This is an argument for building boring, legible systems early — not clever abstractions.
We err toward simplicity and explicit structure at the cost of elegance. Elegance can be added. Complexity is very hard to remove.