Thinking is the most expensive form of stalling.

The cost of inaction is rarely added up. The cost of being wrong usually is. What a real MVP looks like, how 8–14 weeks should be spent, and why "real revenue or a clear no" is the only acceptable outcome.

You have been thinking about it for a year. Some people loved it. Some politely changed the subject. The market is bigger than it looked at first. The market is smaller than it looked at second. You have a list of objections that have to be answered before you can commit. You are still listing them.

This is the most common shape of a stalled founder. The risk you are managing — being wrong about the idea — is real but bounded. The risk you are not managing is the opportunity cost of another year of thinking. A year of thinking does not produce a customer. It produces more thinking.

An MVP is the cheapest answer to the only question that matters: does anyone use this. Not, does anyone want this in the abstract — the answer to that question is always yes if you ask politely. Does anyone, today, with their own time and their own money, use this once it exists. The cheapest way to find out is to build it small and put it in front of someone.

The shape of a real MVP. It is not a prototype. It is not a clickable Figma file. It is software that runs, that a stranger can sign up for, that does the one thing the business is about, and that bills the user — even if the bill is one rand — for the value it provides. Anything less than that is research.

Eight to fourteen weeks is the realistic window from Discovery to live. Anything shorter is usually missing something the business needs at launch (legal, payments, the ability to onboard a second user). Anything longer is usually the wrong scope — too many features, too many edge cases, too many "what if" branches. The right MVP solves one painful problem for one specific person and is honest about what it does not do yet.

The hard part is not the build. The hard part is the discipline of saying no to features. Every feature added to the MVP doubles its complexity and adds two weeks to launch. Every feature removed makes the MVP easier to explain, easier to use, easier to evaluate. The shortest path to a real signal is the most aggressive cut.

What an MVP should produce. Real users — at least fifty in the first month, ideally five hundred. Real feedback — the actual sentences customers say in interviews, not survey averages. Real revenue — even at a token price, paying customers behave differently from free trial users. Or a clear no — which is also a useful answer, and one you can act on.

The wrong reason to build an MVP is to validate that the idea is good. By the time you build it, the idea has either improved or been replaced by something better. The right reason is to give yourself a year of compressed learning in twelve weeks.

The honest version of MVP work. It is not always glamorous. It often produces a result that is the wrong answer to the question you started with. Founders who can change their mind based on the result are the ones the work serves; founders who cannot are usually better off staying with their day job.

→ Find out whether your idea is worth building. Book a Discovery.