MVP

Minimum viable product: the smallest version that delivers real value and generates validated learning about the market.

An MVP is the smallest thing you can ship that a real customer can use to solve the problem, and that generates evidence. Evidence means someone pays, retains or actively abandons, and either answer teaches you something a spec review never would. The classic trap is reading MVP as minimum: the viable part is the hard half, a product too stripped to deliver value validates nothing except that broken things do not sell.

Why it matters to an indie builder: your scarcest resource is months, and MVP discipline is how you buy more of them. Every feature cut before launch is a feature you can add later with revenue-informed priorities instead of guesses. The build-measure-learn loop only spins if the first build is small enough to finish.

A concrete example: an invoicing tool for freelance designers. Full vision: invoicing, time tracking, expense capture, client portal, bank sync. MVP: create and send an invoice, mark it paid, and a basic reminder email. Six weeks to ship instead of nine months. Fifty freelance designers start using it; 11 keep sending invoices monthly, and they ask, unprompted, for recurring invoices, not one of the three cut features. The validated product roadmap now writes itself from paying behavior.

Common mistakes: shipping a landing page and calling it an MVP when no value is delivered to anyone, the smoke test is a marketing experiment, not a product one, polishing instead of launching, the extra month of UI work delays the learning without changing it, defining viability by opinion (set a falsifiable target before launch: 20 users active in week four, or 5 paying, or pivot), and MVPing features that are the product, an invoicing tool that cannot send invoices has not been minimally scoped, it has been gutted. The stack choices on IndieBoot, framework plus database plus payments, are sized so the first loop finishes in weeks.