TL;DR: Building the software is the part everyone plans for. Launching a product is the part that decides whether any of it mattered. Going 0 to 1 takes four things beyond a working build: a specific user with a specific problem, the smallest version that genuinely solves it, a distribution plan that exists before launch day rather than after, and instrumentation honest enough to tell you whether people came back. Below is how we actually take products from idea to live users, drawn from the products we build, own and run ourselves, and the honest signs your idea isn't ready for a build yet.
Most people who come to us with a product idea have already decided the hard part is engineering. It usually isn't. We ship production software in days, so the build is rarely what stands between an idea and a real business. What stands there is everything around the build: whether the problem is sharp enough, whether the first version is small enough to learn from, and whether anyone will ever find out the thing exists. This is the part that separates a product from an expensive app.
A project ends. A product starts.
The distinction matters more than it sounds. A project has a finish line: a defined deliverable, an acceptance date, a handoff. A product has a beginning: the day it goes live is the day you start learning what's actually wrong with it. Client work is often the former. A 0-to-1 product is always the latter.
Teams that treat a product launch like a project delivery get a predictable outcome. The software works, the invoice clears, and nothing happens. There are no users, because acquiring them was never scoped, and there's no second version, because the budget ended at launch. The build was fine. The product never existed.
If what you actually need is a defined system for a business you already run, that's a custom build with a clear finish line, and you should scope it that way. If you're trying to create something new that strangers will choose to use, keep reading, because you're signing up for a loop, not a delivery.
The four things 0 to 1 actually requires
1. A specific user with a specific problem
The single most common reason a 0-to-1 product dies is that it was built for "people who want to be more organized" instead of a person you could describe in one sentence. Broad definitions feel safer because they imply a bigger market. In practice they make every product decision harder, because with no specific user in mind you have no way to choose between two features, and you end up building both.
Sharp beats broad at this stage. LectureNotes AI is an AI note-taking app for students recording lectures. That's a person, a moment and a job, and it makes the roadmap obvious: recording quality matters, summaries have to survive a bad microphone in a big hall, outlines have to be usable the night before an exam. Fyuel is an accounting platform for the fuel trade, not for businesses generally, which is exactly why it can carry tankers, suppliers and ledgers as first-class concepts. Narrow definitions don't shrink your market. They earn you the first slice of it.
Before we build anything, we push on this: who is the first user, what do they do today instead, and why is today's workaround bad enough that they'd switch. If those three answers are vague, the build isn't the problem to solve yet.
2. The smallest version that genuinely solves it
The word "minimum" gets abused in both directions. Some teams ship something so thin it doesn't solve the problem, learn nothing except that a broken thing is unpopular, and conclude the market isn't there. Others spend nine months gold-plating a v1 nobody asked for and learn the same lesson far more expensively.
The useful test is whether the first version closes the loop for one user on one job, end to end. Not every job. One. It can be ugly at the edges, but the core has to actually work, because you're testing whether the value is real, and a broken version can't tell you that. Everything outside that loop is a candidate for later: extra user types, settings, admin panels, the second platform.
We wrote up how to size and price that first version in our guide to MVP costs, including where budgets actually leak. The short version: scope is the lever, and the discipline is deciding what you're deliberately not building in v1.
3. A distribution plan that exists before launch day
This is the one that gets skipped, and it's the one that kills the most products. "We'll launch and see" is not a plan. Neither is "we'll do some marketing after."
Distribution has to be part of the product decision from the start, because it changes what you build. A product that grows through search needs content and pages that can rank. A product sold to businesses needs a demo path and a way to book a conversation. A consumer app needs something worth showing in a fifteen-second video, which is a real design constraint, not a marketing afterthought. If you decide the channel after the build, you'll usually discover the product isn't shaped for it.
This is why our own products are built alongside people who know the demand side. LectureNotes AI is built with Benjamin Rhodes, Lifemaxxing AI with Benjamin Siegel, and VoiceDash with Victor Smush, and our team includes marketers who run content and social for our apps rather than only engineers. Product Innovation as a service means the 0-to-1 build and the go-to-market are the same conversation. Ask any studio you're evaluating what happens the week after launch. If the answer is "we hand it over," you're buying a project.
4. Instrumentation you're willing to believe
You cannot iterate on a feeling. From day one, you need to see activation (did a new user reach the value at all), retention (did they come back without being nudged), and where people fall out of the core flow. Three honest numbers beat a dashboard of forty vanity metrics.
Retention is the one that tells the truth. Acquisition can be bought or borrowed for a launch week, but coming back is the only signal that the product solved something. If people activate and don't return, adding features rarely fixes it, and the honest move is to change the wedge or the audience rather than to build more. Instrument the core loop before launch, not after. Retrofitting analytics onto a live product is one of those small tasks that quietly never gets done.
How AI changed the 0-to-1 math
The build cost of a first version has genuinely collapsed. Senior engineers working with AI coding agents under review compress what used to be months into days, which is the whole basis of how we ship. For a founder, that shifts the economics in two ways.
First, being wrong got much cheaper. When a v1 costs a fraction of what it used to, you can afford to test a sharper, narrower idea and kill it fast if the numbers say so. The old incentive was to load everything into v1 because a second build was expensive. That incentive is largely gone.
Second, and less comfortably, the build stopped being the moat. If you can ship a working product in weeks, so can everyone else. What's scarce now is the specific insight, the distribution, and the willingness to keep iterating after launch when it's less fun than starting. AI compressed the engineering, not the judgment. Any studio telling you speed alone is the advantage is selling you the easy half.
How we run a 0-to-1 build
The discipline mirrors how we scope everything else: name the shape before anyone writes code.
- Define the first user and the job. One person, one problem, one moment. If we can't state it in a sentence, we work on that before we quote a build.
- Cut v1 to one closed loop. The smallest version where that user gets the value end to end, with a written list of what we're deliberately leaving out.
- Decide the channel while scoping. How the first hundred users arrive shapes what gets built, so it's a build decision, not a later one.
- Instrument activation and retention on day one. Three numbers we'll actually look at, wired before launch.
- Plan the loop after launch. Who reviews the data, how fast v1.1 ships, and what would make us change direction rather than add features.
Pin those down and 0 to 1 stops being a gamble on taste. Skip them and you've commissioned software, which is a different and much sadder purchase.
Where we fit
Null Studio doesn't only build products for other people. We build, own and run our own, with US partners and real users: LectureNotes AI, Lifemaxxing AI, VoiceDash and Fyuel. That means when we scope your 0 to 1, we're bringing the scars from launching our own things, not just delivery experience.
We also take on the parts most studios treat as someone else's job: custom AI agents where the product needs them, mobile and web builds, growth and analytics, and engineers plugged into your team if you'd rather own the build with our help. And if the honest answer is that your idea isn't ready for a build yet, we'll say so, because burning your budget on a v1 aimed at nobody in particular helps neither of us.
Buyer checklist
Before you commission a 0-to-1 build from anyone, get these answers.
- Ask them to state your first user and job in one sentence, back to you. If they can't, they haven't understood the product.
- Get the v1 exclusion list in writing: what they're deliberately not building, and why.
- Ask how the first hundred users arrive, and confirm that answer shaped the scope.
- Confirm activation and retention are instrumented before launch, not after.
- Ask what happens the week after launch, and who's on the hook for v1.1.
- Ask what would make them tell you to stop, because a partner who can't imagine that outcome isn't evaluating your idea, just your budget.
Going 0 to 1 isn't primarily an engineering problem anymore. It's a problem of aim, restraint, distribution and the discipline to keep going after the launch buzz fades. Get those right and a small, fast build is enough to find out if you're onto something. Get them wrong and no amount of engineering saves it.
Null Studio takes products from zero to launch: the build, the go-to-market and the iteration after, with the same team that ships and runs our own products. Book a demo and we'll give you a straight read on your idea, including whether it's ready for a build yet. See our work: 40+ products shipped worldwide, in days, not months.