MVP aplikace: co do první verze patří a co ne

Krátká odpověď: MVP (minimum viable product) je nejmenší verze aplikace, která už řeší jeden skutečný problém skutečných uživatelů a dá se na ní změřit, jestli ji chtějí. Do MVP patří jedna hlavní cesta uživatele od začátku do konce, základní bezpečnost a měření. Nepatří do něj všechno, co by „bylo fajn mít“, ani příprava na škálování, které ještě nepřišlo.

Proč na tom záleží

MVP je pojem, který zná každý a každý ho používá jinak. Pro někoho je to klikací prototyp, pro jiného produkt se všemi funkcemi, jen trochu ošizený. Přitom na tom, jak si ho vyložíte, závisí, kolik peněz a měsíců utratíte dřív, než se něco dozvíte.

Pro člověka, který rozhoduje o rozpočtu, je rozdíl zásadní. Příliš malé MVP nic neověří, protože ho lidé nedokážou použít. Příliš velké MVP spotřebuje peníze a měsíce dřív, než se dozvíte, jestli produkt vůbec někdo chce. A s nástupem vibe codingu přibyla třetí past: MVP vznikne za víkend, ale nikdo se neptal, co má ověřit.

Plánujete první verzi a nevíte, kde udělat čáru? Domluvte si 30 minut online s námi. Projdeme váš seznam funkcí a řekneme vám, co bychom nechali na později. Domluvit online call

Co MVP je a co není

MVP je experiment, ne malý produkt. Pojem zpopularizoval Eric Ries v knize The Lean Startup (2011) jako verzi produktu, která umožní naučit se co nejvíc o zákaznících s co nejmenším úsilím. Klíčové slovo je „naučit se“. MVP má odpovědět na otázku, ne předvést, co všechno umíte postavit.

Z toho plyne, co MVP není:

• Není to prototyp. Prototyp ukazuje, jak by produkt mohl vypadat. MVP už někdo reálně používá a vy měříte, co dělá.
• Není to beta verze plného produktu. Beta je hotový produkt s chybami. MVP je záměrně neúplný produkt bez chyb v tom mále, co dělá.
• Není to ošizená verze. Nešetří se na kvalitě hlavní funkce. Šetří se na počtu funkcí.

U nás v MeguMethod se ptáme na jednu věc dřív, než se začne mluvit o funkcích: jakou otázku má první verze zodpovědět? Když ji neumíme formulovat jednou větou, není ještě čas stavět.

Co do MVP patří

Do MVP patří jedna cesta uživatele, kterou projde celá bez pomoci. Všechno ostatní je kandidát na vyřazení.

• Jedna hlavní cesta od začátku do konce. Uživatel přijde, udělá to, kvůli čemu přišel, a odejde s výsledkem. U rezervační aplikace je to rezervace, u nástroje na reporty jeden hotový report. Ne pět cest napůl.
• Přihlášení a základní bezpečnost. Jakmile aplikace ukládá data o lidech, musí každý vidět jen svoje. To není funkce navíc, to je podmínka, aby ji šlo dát cizím lidem.
• Měření. Kolik lidí přišlo, kolik dokončilo hlavní cestu, kolik se vrátilo. Bez těchto tří čísel MVP nic neověří, i když funguje.
• Způsob, jak vám uživatel řekne, co mu chybí. Formulář, e-mail, tlačítko. Nejcennější výstup MVP jsou věty od lidí, ne grafy.
• Zálohy a oddělené prostředí. Nejmenší možná verze provozní hygieny. Ztráta dat prvních deseti zákazníků je horší než chybějící funkce.

Co do MVP nepatří

Do MVP nepatří nic, co řeší problém, který ještě nemáte. To je nejjednodušší test při každém požadavku na funkci.

• Správa rolí a oprávnění pro velké týmy. Dokud máte deset zákazníků, stačí uživatel a admin.
• Integrace na všechno. Jedna integrace, která je pro hlavní cestu nutná, ano. Napojení na pět systémů „protože to zákazníci budou chtít“, ne. Až to budou chtít, řeknou vám který.
• Příprava na škálování. Aplikace pro sto uživatelů nemusí být postavená pro sto tisíc. Musí být postavená tak, aby šla přestavět, až těch sto tisíc přijde.
• Vlastní design systém a animace. MVP má být přehledné a důvěryhodné. Nemusí být krásné.
• Nativní mobilní aplikace, když stačí web. Pokud hlavní cesta nepotřebuje fotoaparát, polohu nebo notifikace, web v mobilu ověří totéž za zlomek času.
• Nastavení, možnosti a přizpůsobení. Každá volba pro uživatele je rozhodnutí, které jste neudělali vy. V MVP rozhodujete vy.

Praktický postup: sepište všechny funkce, které vás napadají, a u každé odpovězte na otázku „ověří tahle funkce to, co chceme vědět?“. Co má ne, jde do seznamu na později. Ten seznam nezahazujte, je to základ druhé verze.

Jak velké má MVP být

Správná velikost MVP se pozná podle toho, že se vám za něj trochu stydíte, ale uživatel ho dokáže použít bez vás. Pokud musíte každému vysvětlovat, co kam kliknout, je příliš malé. Pokud ho stavíte půl roku, je příliš velké.

Dobrý orientační rámec je čas do prvního skutečného uživatele. Když se počítá v týdnech, jste na správné cestě. Když v měsících, je v rozsahu něco, co tam nepatří. To platí bez ohledu na to, jestli MVP stavíte s AI nástroji, interně, nebo s partnerem.

MVP s AI, nebo s týmem?

Vibe coding změnil ekonomiku MVP. První verzi, která dřív stála týdny práce vývojáře, dnes zakladatel poskládá za pár dnů v nástroji jako Lovable nebo s Claude Code. To je dobrá zpráva, pokud víte, co ověřujete.

Náš pohled v MeguMethod: AI nástroje jsou nejlepší cesta k MVP, které má ověřit zájem. Jakmile se ukáže, že zájem existuje, přichází druhá fáze: z MVP udělat produkt, který obstojí v produkci. Tam už je častěji potřeba tým, protože se řeší bezpečnost, integrace a výkon, tedy věci, které prompt zvládá hůř než člověk. Co přesně se v té fázi dotahuje, popisujeme v checklistu připravenosti AI-built aplikace pro skutečné uživatele.

Důležité je nerozhodovat se jednou provždy. MVP s AI a produkt s týmem nejsou dvě konkurenční cesty, ale dvě fáze stejné cesty.

Kdy MVP stavět a kdy ještě ne

MVP stavte, když:

• umíte jednou větou říct, co má ověřit,
• máte aspoň deset lidí, kteří ho budou používat a řeknou vám, co si myslí,
• víte, jaké číslo bude znamenat úspěch a jaké ne,
• máte rozpočet na týdny, ne na měsíce.

Ještě počkejte, když:

• rozhodujete se mezi třemi různými nápady a MVP má být pro všechny,
• nemáte koho se zeptat, jestli produkt chce, a plánujete to zjistit až reklamou,
• hlavní cesta uživatele závisí na integraci, kterou ještě nemáte dohodnutou,
• první verze musí ze zákona nebo smlouvy splnit požadavky, které MVP splní jen těžko (zdravotnictví, finance). Tam se začíná jinak.

Pokud se poznáváte ve druhém seznamu, není ještě čas na MVP, ale na discovery: krátkou fázi, kdy si ujasníte problém, uživatele a možná řešení dřív, než se začne stavět. V MeguMethod ji děláme jako strategickou analýzu s malým týmem, ve kterém je product lead, UX/UI designér a seniorní vývojář. Výstupem je mapa uživatelů a jejich cest, alternativy řešení a návrh architektury, ze kterých se pak dá první verze vymezit s jistotou.

Máte nápad a chcete ho ověřit dřív, než do něj dáte větší peníze? Podívejte se, jak probíhá naše strategická analýza, nebo nám rovnou napište pár vět o tom, co má první verze zodpovědět. Připravíme pro vás discovery workshop na míru. Poslat poptávku

Jak k tomu přistupuje MeguMethod

Když ještě není jasné, co má první verze ověřit, začínáme strategickou analýzou, tedy discovery fází, ve které s vámi zmapujeme uživatele, jejich cesty a alternativy řešení. Špatné nápady tak padnou dřív, než stihnou stát peníze.

Když je cíl jasný, první krok v App as a Service je schůzka, kde si ujasníme cíl, rozsah, termín a cenu. Na ní se ptáme na jednu věc dřív než na funkce: co má první verze zodpovědět. Pak z nápadu uděláme aplikaci a spustíme ji naostro, bez mockupů a klikacích prototypů, protože první verze má být něco, co lidé používají. Součástí je architektura, testy a pravidla pro nasazování, aby se na ní dalo stavět dál.

Co do první verze nepatří, neztrácíme. Dáme to do plánu dalšího rozvoje a probíráme ho s vámi při pravidelných revizích. Další úpravy si pak můžete dělat s AI sami, s našimi nástroji a návodem, a každou změnu před spuštěním zkontroluje naše AI i naši experti. Jak funguje App as a Service

Další krok

Máte první verzi a chcete z ní udělat produkt pro zákazníky? Podívejte se, jak funguje App as a Service, nebo si rovnou domluvte 30 minut online. A pokud ještě nevíte, co má první verze ověřit, začněte strategickou analýzou.