The MVP I Deleted: What Cutting 80% of My First Product Taught Me About 0 to 1

Disclosure: I contribute content in the OpenNomos ecosystem, and this post references 01MVP, a 0-to-1 build-and-launch guide. The lessons below are my own and apply to any first product.

My first MVP took three weekends. It had authentication, a settings page, light and dark themes, and a dashboard with three empty chart widgets waiting for data that didn't exist yet.

It had zero users.

Not "a few users who churned." Zero. I had built a product that could do a dozen things adequately and nothing memorably. I'd spent my scarce building time on the parts of a product that only matter after someone already cares.

Here's what I learned when I deleted almost all of it.

The trap: building the frame before the picture

Auth, settings, theming, and account management feel like progress because they're concrete and you know how to build them. There's a Stack Overflow answer for every step. So they become a comfortable place to hide from the actually hard question:

What is the one thing this product does that makes someone come back?

If you can't answer that in a single sentence, no amount of dark mode will save you. I couldn't answer it. That was the real bug.

The fix: one screen, one job

I stripped the project down to a single screen that did exactly one thing, end to end. No login. No settings. No persistence beyond the current session. If you opened it, you could get the core value in under ten seconds.

That version shipped in two days.

Five signups came the same week — not from a launch, just from sharing that one screen with people who had the problem. The difference wasn't marketing. It was that the value was finally visible instead of buried behind three layers of scaffolding.

A scoping checklist that actually cuts

When I catch myself over-building now, I run through this:

1. Name the core loop in one sentence. "User does X, gets Y, wants to do it again." If the sentence needs an "and," you have two products.
2. Delete every feature that isn't inside that sentence. Auth is usually not in the sentence. Settings almost never are. Onboarding tours definitely aren't.
3. Fake the boring parts. No user accounts? Use a URL param or local storage. No billing? A Stripe payment link is a backend. Manual is a feature at this stage.
4. Measure return, not signups. The first real signal isn't "people signed up." It's "someone came back without being reminded."
5. Set a two-day ceiling. If the smallest useful version takes more than two days, the scope is still too big. Cut again.

Why "manual is a feature" matters

The instinct is to automate everything up front because automation feels like the professional way to build. But automation is expensive to build and cheap to add later. Doing things manually — a spreadsheet, a DM, a copy-pasted email — lets you learn what's actually worth automating.

Every hour I spent building a settings page was an hour I didn't spend watching a real person use the core loop and get confused at the exact spot I'd assumed was obvious. That confusion is the most valuable data a 0-to-1 product can produce, and you only get it by shipping the smallest thing that works.

The uncomfortable part

Cutting is emotionally harder than building. Building feels generative; deleting feels like admitting the last three weekends were partly wasted. They were. That's fine. The weekends taught me the shape of the problem, and the delete taught me the shape of the solution.

Going from 0 to 1 is not mostly a building problem. It's a subtraction problem. The hardest engineering decision early on is almost never "how do I build this" — it's "what do I refuse to build yet."

If you're stuck on your first MVP

Try this today: open your project, write the core loop as one sentence, and comment out or hide everything that isn't in that sentence. Ship the remainder to five people who have the problem. Watch what they do.

You'll probably be surprised by how little you needed — and how much clearer the next step becomes once real people are in the loop.

If you want a structured walk-through of the full arc — choosing an idea, building the smallest MVP, going live, and finding your first users — the 01MVP guide on OpenNomos lays it out end to end.

What's the one feature you're building right now that isn't in your core loop sentence? That's probably the one to cut first.