Zero-index thinking: Building your first product
What "zero-index" means as a builder — starting from first principles, ignoring incumbents, and shipping before you're ready.
---
In programming, arrays are zero-indexed. The first element is at position zero, not position one. This is not a convention that makes intuitive sense to most people encountering it for the first time. We count from one. We have always counted from one. The first thing is the first thing — why would you call it the zeroth?
The answer is that zero-indexing is more honest about what is actually happening. The index is not an ordinal — it is an offset from the start. Zero means no offset. One means one step away. The system is describing something real about the structure of memory, even if it is initially uncomfortable.
I use this as a metaphor for a particular way of building.
---
What incumbents teach you that you shouldn't learn
When you decide to build something, the first instinct is to study what already exists. How do other apps in this space work? What have successful products done? What are the best practices?
This is useful information. It is also a trap.
Studying incumbents teaches you their answers to their questions, in their context, with their constraints. Those constraints are often invisible — technical decisions made five years ago, organisational structures that shaped what was possible, user bases that were different from yours. The answers look like universal truths but they are not. They are solutions to specific problems, frozen in time.
Zero-index thinking means starting one level below the incumbent's answers. Not "how does Notion organise a workspace?" but "what does a person actually need when they are trying to capture and organise thought?" Not "how does Figma handle layers?" but "what is the real cognitive challenge in designing a complex layout?" The incumbent answers the surface question. The zero-index question goes to the substrate.
This is harder. It requires sitting with uncertainty for longer. It produces no immediate direction. But it occasionally produces products that feel qualitatively different from everything else in their category — because they were designed from first principles rather than by analogy.
---
Shipping before you're ready
The other half of zero-index thinking is temporal.
There is a readiness that product builders wait for that never arrives. The design isn't finished. The edge cases aren't handled. The performance isn't where it should be. The copy isn't right. The onboarding flow needs another iteration. The feature set isn't complete enough to show to anyone.
All of this is true and none of it is the real reason for not shipping.
The real reason is that shipping is a confrontation with reality. As long as the product lives in your head or your staging environment, it can be as good as you imagine it. The moment it is in front of a real user, you learn things that are uncomfortable. They don't use it the way you expected. They get stuck in places you thought were obvious. They care about something you deprioritised and don't care about something you laboured over.
Zero-index thinking treats this confrontation as the beginning of the work, not the end. The first version is not the product. It is the question you are asking reality. The answer — in the form of what real users actually do with what you built — is worth more than any amount of internal iteration.
This is not an argument for shipping broken things. It is an argument for shipping the minimum honest version of the idea — the thing that makes the core proposition real, removes everything else, and gets it in front of someone who isn't you as quickly as possible.
---
The zero in practice
When I built ARIA — a wealth management copilot for financial advisors — the first version had one feature: given a client name, summarise their portfolio position in plain language. No authentication. No dashboard. No export. One feature that did one thing.
It was enough to learn the most important thing: advisors didn't need a summary. They needed to be able to ask a question. The framing was wrong. The thing I thought was the core feature was actually peripheral. The real feature was the conversational interface I hadn't built yet.
I would not have learned that from any amount of competitive analysis or design iteration. I learned it from shipping the minimum version and watching what someone did with it.
That is what zero-index means as a practice. Not naivety. Not ignoring everything that exists. Starting the count from zero — from the actual substrate of the problem, before the conventions and assumptions and best practices accumulate — and finding out what is true before deciding what to build.