What an MVP is actually for

An MVP has one job: to test your most important assumption as cheaply and quickly as possible.

Not to impress investors. Not to launch publicly. Not to demonstrate what the full product will look like. To answer one question: does this solve a real problem for a real person well enough that they'd use it again?

Everything that doesn't help you answer that question is scope creep. Cut it.

How to find your most important assumption

Every product is built on a stack of assumptions. Some are safe. Some will kill you if they're wrong.

Your most important assumption is usually the one you're least sure about — and the one the whole business depends on. Write them down explicitly. Not the ones you're confident about. The ones that scare you.

Then ask: what's the cheapest way to test whether this assumption is true?

Often the answer isn't a product at all. It's a conversation, a manual process, or a mockup. If you can test the assumption without building anything, test it first. Build after.

The cut list most founders ignore

Features that would be nice to have but don't test your core assumption — cut.

A polished UI that makes the product look finished — cut. Ugly and functional beats beautiful and useless at this stage.

Integrations, admin dashboards, notification systems, settings pages — cut. None of these test whether your product solves a real problem.

What's left after you cut everything is your MVP. If it still feels too big, cut again.

The real reason founders overbuild

It's not incompetence. It's fear. Building feels like progress. Shipping a minimal version feels like exposure — like people will judge you for what's missing instead of what's there.

The founders who ship early and iterate fast aren't more confident. They're just more focused on learning than on looking good.