How to take an app from 0 to 1

Every 0-to-1 project looks the same from the outside: a small team, a big idea, and a clock. What separates the ones that ship something real from the ones that quietly disappear is rarely talent. It's sequencing.

The short version: 0→1 is two jobs, not one. First de-risk — find the assumption that could kill the idea and test it before you build. Then design and build the smallest version real users will actually use. Teams that skip the first job don't move faster; they build the wrong thing with more confidence.

What "0 to 1" actually means

It isn't a feature list. It's the distance from an idea to the first version a stranger uses — and, if you're lucky, pays for. That hides two very different pieces of work: deciding what's worth building, and building the smallest real version of it. Conflating them is the most common and most expensive mistake in the whole exercise.

Phase 1 — De-risk before you build

Write down the five things that have to be true for this to work. Rank them by how scared you are of being wrong. Then test the scariest one the cheapest way you can: a rough prototype, a fake-door page, five real users. Five is enough — testing with five users surfaces most usability problems (Nielsen Norman Group).

The uncomfortable statistic: the single most common reason startups fail is that there was no market need — about 35% of them (CB Insights). A market-need test costs a week; finding out at launch costs a year. The goal in Phase 1 isn't to feel good about the idea — it's to try to prove it wrong while that's still cheap (Y Combinator, on talking to users).

Phase 2 — Design the v1

Scope to one job done well. Work out the information architecture, the core flow, and the argument the product makes on its very first screen. Write it plainly. The designer's job here isn't to make it look finished — it's to make the smallest possible thing feel inevitable, so the team can build it without guessing.

Phase 3 — Build to learn, not to scale

Ship the smallest real product, instrument it, and expect to change it. Decide up front who owns the technical roadmap: you want a specification you own, not a Figma link you can't hand to an engineer. Build for the first hundred users, not the first million — scaling is a problem you earn the right to have.

Why 0-to-1 goes wrong

Four failure modes we see over and over: building before validating (six months, wrong product); a design-only handoff nobody can build around; putting junior hands on a project where judgement is the product; and chasing polish over proof.

How to judge a 0-to-1 partner

Whoever you hire, judge them the same way: do they ask about users, metrics and workflows before showing screens? Do they challenge the premise, or just take the feature list? Are senior people on the work day to day, or a pitch team? And will they measure outcomes — activation, retention — rather than deliverables?

How we do it

Memeador is a product design shop for startups and enterprise teams. On a 0→1, we start with the assumption that scares you most, test it cheaply, and then design and build v1 around whatever survives. We'd rather spend a week disproving the idea than a quarter building on top of a guess.

If you're about to spend real money building something nobody has tested, the cheapest hour you'll ever spend is the one where you try to prove it wrong. Get in touch: thecollective@memeador.com