MVP aplikacji: co to jest i czym różni się od prototypu

Najkrócej: MVP to pierwsza wersja w sklepach, która sprawdza rynek. U nas powstaje w około 8 tygodni i kosztuje od 50 000 zł netto, a zaczyna się od 1-2 tygodni prototypu i planu za 17 500 zł netto. Od tego, co wpiszesz w umowę jako MVP, zależy budżet, termin i to, czego się z tej wersji dowiesz.

MVP aplikacji: co to jest?

MVP to skrót od minimum viable product. Po polsku najczęściej mówi się "minimalna wersja produktu" albo "minimalny opłacalny produkt". W praktyce to pierwsza wersja aplikacji, która trafia do prawdziwych ludzi i robi jedną rzecz na tyle dobrze, że da się zmierzyć, czy ktoś jej potrzebuje.

Ważne są oba człony. "Minimum", bo budujesz tylko to, bez czego aplikacja nie ma sensu. "Viable", bo ta wersja musi działać naprawdę: z kontami użytkowników, danymi, publikacją w App Store i Google Play. Popularność pojęcie zawdzięcza książce "The Lean Startup" z 2011 roku i jej pętli: zbuduj, zmierz, wyciągnij wnioski.

Wersja MVP aplikacji to więc nie makieta ani demo. To produkt, który ktoś pobiera, używa i do którego wraca albo nie. Właśnie tę odpowiedź ma ci dać MVP.

Prototyp, PoC, P2P i MVP: czym się różnią?

Te cztery rzeczy często wrzuca się do jednego worka. Każda odpowiada na inne pytanie i każda kosztuje inaczej.

W skrócie: prototyp sprawdza pomysł na ekranach, PoC sprawdza technologię, MVP sprawdza rynek. Prototyp powstaje w dni albo tygodnie, MVP w tygodnie albo miesiące. Z prototypu zostają decyzje i design, z MVP zostaje kod, na którym budujesz dalej.

Prototyp czy MVP: od czego zacząć?

Prawie zawsze od prototypu. Ekran poprawiony w prototypie to chwila pracy designera. Ten sam ekran poprawiony w gotowej aplikacji to zmiana w kodzie, w backendzie i ponowne testy.

• Zacznij od prototypu, gdy masz pomysł, ale nie masz pewności, jak mają wyglądać kluczowe ekrany, gdy chcesz pokazać produkt wspólnikowi albo inwestorowi, albo gdy kierunków jest kilka i trzeba wybrać jeden.
• Idź od razu w MVP, gdy ekrany są już przemyślane (na przykład masz prototyp z AI albo projekt w Figmie) i najważniejsze pytanie brzmi: czy ktoś będzie z tego korzystał.
• Zrób PoC, gdy cały pomysł stoi na jednym technicznym założeniu, którego nikt jeszcze nie sprawdził.

Przykład z naszej pracy: przy Prencie, aplikacji do domowych list zadań, były cztery rundy prototypu. Przeklikaliśmy 195 ekranów, a do aplikacji przeszło 10 najlepszych. Gdyby każdy z tych kierunków budować w kodzie, budżet skończyłby się na trzeciej rundzie.

Jak zrobić prototyp aplikacji mobilnej?

Nie potrzebujesz do tego programisty. Potrzebujesz jasno opisanego problemu i kilku rozmów z ludźmi, którzy go mają.

• Opisz problem jednym zdaniem. Kto go ma, kiedy i ile go to kosztuje. Jeśli nie da się tego zapisać w jednym zdaniu, prototyp też nie będzie jasny.
• Wybierz jeden główny proces. Na przykład: zapisz połów i zobacz go na mapie. Wszystko inne na razie odkładasz.
• Narysuj 3-5 kluczowych ekranów. Na kartce, w Figmie albo w narzędziu AI. Narzędzia takie jak Lovable pozwalają dziś złożyć klikalną wersję bez programisty.
• Daj go do przeklikania. Kilku osobom z grupy docelowej, na ich telefonie. Nie tłumacz, tylko patrz, gdzie się zatrzymują.
• Popraw i powtórz. Druga i trzecia runda zwykle uczą więcej niż pierwsza.

Przy rozmowach nie sprzedawaj pomysłu, tylko słuchaj. Pytaj o przeszłość, nie o deklaracje na przyszłość:

• Co jest najtrudniejsze w [twój problem]?
• Kiedy ostatnio się z tym zmierzyłeś i jak to wyglądało?
• Co już zrobiłeś, żeby to rozwiązać?
• Czego brakuje w rozwiązaniach, których używasz dziś?

Gdy słyszysz ogólną odpowiedź, dopytuj "dlaczego?", aż dojdziesz do konkretnej przyczyny. To proste narzędzie, a oszczędza tygodnie budowania funkcji, o które nikt nie prosił.

Masz już prototyp z Lovable, Bolta albo Replita i zastanawiasz się, co dalej? Opisaliśmy to osobno: aplikacja z Lovable w App Store.

Co powinna zawierać wersja MVP aplikacji?

Jedną rzecz, zrobioną porządnie. Najczęstszy błąd to MVP, które próbuje być pełnym produktem, tylko gorszym. Drugi to MVP tak okrojone, że nie da się na nim niczego sprawdzić.

Zanim spiszesz funkcje, nazwij swoje najbardziej ryzykowne założenie. Na przykład: "wędkarze będą zapisywać połowy w aplikacji, a nie w zeszycie". MVP ma sprawdzić właśnie to, najmniejszym możliwym kosztem.

U nas MVP zwykle wygląda tak:

• Aplikacja na iOS i Androida, do około 10 ekranów i jeden główny proces.
• Logowanie przez e-mail, Apple i Google.
• Prosty backend na twoim własnym koncie w chmurze.
• Podstawowy panel admina: użytkownicy i treści.
• Powiadomienia push, analityka i raporty awarii.
• Publikacja w App Store i Google Play.

Poza zakresem pierwszej wersji zostają zwykle płatności i subskrypcje, czat w czasie rzeczywistym i integracje z innymi systemami. Dochodzą w kolejnych etapach, gdy MVP pokaże, że warto.

Analityka to nie dodatek. Bez niej MVP nie odpowie na swoje pytanie. Zanim ruszy budowa, ustal, po czym poznasz, że działa: ilu użytkowników wraca po tygodniu, ilu kończy główny proces, ilu pyta o płatną wersję.

Jak wygląda tworzenie MVP aplikacji krok po kroku?

Tak wygląda to u nas, od pierwszej rozmowy do aplikacji w sklepach:

Co tydzień dostajesz nową wersję na swój telefon. Nie czekasz dwóch miesięcy, żeby zobaczyć, co powstaje.

Dlaczego szybkość ma znaczenie?

Każdy miesiąc budowania bez użytkowników to miesiąc zgadywania. Szybkie MVP nie oznacza bylejakości. Oznacza krótszą drogę do pierwszych danych i mniej pieniędzy wydanych, zanim się okaże, czy pomysł chwyta.

Szybkość zależy też od rzeczy poza kodem. Konto firmowe w Google Play wymaga numeru D-U-N-S, a Google uprzedza, że jego uzyskanie może potrwać do 30 dni. Apple też wymaga go od firm. Nowe konta prywatne w Google Play muszą z kolei przejść test zamknięty: co najmniej 12 testerów przez co najmniej 14 dni bez przerwy. Warto to uruchomić w pierwszym tygodniu, a nie w ostatnim.

Od czego zaczynały znane aplikacje? Przykłady MVP

Airbnb zaczęło w 2007 roku od dmuchanych materaców w salonie założycieli, wynajmowanych gościom konferencji w San Francisco, gdy w mieście brakowało noclegów. To wystarczyło, żeby sprawdzić, czy obcy ludzie chcą spać u obcych ludzi.

Dwa przykłady z naszych projektów:

• FishPRO. Aplikacja dla wędkarzy zaczęła od szybkiego MVP, żeby sprawdzić rynek. W sklepach była po 2 miesiącach. Dopiero potem wersja 2.0 przepisała każdą funkcję na nową architekturę, z nowym designem. Dziś ma ocenę 4,5 w App Store przy 34 opiniach.
• Museo. Zanim aplikacja dla zwiedzających ruszyła na dobre, jako MVP wydaliśmy aplikację Ambassador: narzędzie, którym pracownicy muzeum fotografują dzieła i uruchamiają generowanie opisu i narracji przez AI. Najpierw sprawdziliśmy cały obieg, potem skalowaliśmy.

W obu przypadkach MVP nie było wersją "na próbę" do wyrzucenia. Było pierwszym krokiem produktu, który rozwija się dalej.

O co zadbać w umowie na stworzenie aplikacji mobilnej?

Polskie przewodniki o MVP prawie nie poruszają tego tematu, a to tu najczęściej zaczynają się kłopoty. Program komputerowy jest w polskim prawie chroniony jak utwór (art. 74 ustawy o prawie autorskim). Jeśli umowa niczego nie mówi o prawach, kod może prawnie należeć do wykonawcy, nawet jeśli zapłaciłeś za całą pracę.

• Przeniesienie autorskich praw majątkowych. Umowa przenosząca prawa wymaga formy pisemnej pod rygorem nieważności (art. 53). Wystarczy papier albo kwalifikowany podpis elektroniczny. Sam mail z akceptacją nie wystarczy.
• Pola eksploatacji. Prawa przechodzą tylko na pola wyraźnie wymienione w umowie (art. 41 ust. 2). Wpisz co najmniej: utrwalanie i zwielokrotnianie kodu, jego modyfikowanie, rozpowszechnianie, w tym w sklepach z aplikacjami, oraz udostępnianie w sieci.
• Kod źródłowy. Repozytorium na twoim koncie albo przekazane przy każdym odbiorze etapu. Nie tylko plik aplikacji.
• Konta w sklepach na twoją firmę. App Store i Google Play zakładasz na swoją firmę, a wykonawca dostaje dostęp. Przeniesienie aplikacji między kontami później jest możliwe, ale to dodatkowa praca i ryzyko przy każdej zmianie wykonawcy.
• Etapy i odbiory. Stała cena za etap, jasne kryteria odbioru i moment, w którym możesz się zatrzymać. Przy MVP lepiej sprawdza się kilka małych etapów niż jedna duża kwota na końcu.
• Gwarancja. Na jaki czas i co obejmuje. U nas to 6 miesięcy na aplikacje, które budujemy.

To nie jest porada prawna. Umowę przy większym projekcie warto dać do przeczytania prawnikowi, który zna umowy IT.

Przejmujesz aplikację po innej firmie i nie wiesz, co właściwie masz? Zacznij od audytu przed przejęciem.

Dofinansowanie na stworzenie aplikacji mobilnej: czy jest?

Bywa, ale nie jest uniwersalne. Polska Agencja Rozwoju Przedsiębiorczości prowadzi nabory dla startupów, na przykład program Platformy startowe dla nowych pomysłów dla firm z Polski Wschodniej. Warunki, terminy i kwoty zmieniają się z każdym naborem, dlatego nie podajemy ich tutaj. Aktualne nabory są w harmonogramie PARP.

Jeśli liczysz na dotację, sprawdź w regulaminie konkretnego naboru dwie rzeczy, zanim podpiszesz umowę z wykonawcą: od kiedy koszty są kwalifikowalne i jakiej dokumentacji wymaga rozliczenie. Dotacja nie powinna być też jedynym planem. Nabór może się przesunąć, a rynek nie poczeka.

Ile kosztuje MVP aplikacji w Codigee?

• Prototyp i plan: 17 500 zł netto. 1-2 tygodnie. Kluczowe ekrany, klikalny prototyp i stała cena każdego etapu. W 100% zaliczany na poczet budowy.
• MVP: od 50 000 zł netto. Około 8 tygodni. Aplikacja na iOS i Androida we Flutterze, prosty backend, panel admina, publikacja w obu sklepach i 6 miesięcy gwarancji.

Kod i konta w sklepach należą do ciebie od pierwszego dnia. Zaczynamy zwykle około 2 tygodnie po podpisaniu umowy.

Od czego zależy cena większej aplikacji i ile kosztuje jej utrzymanie, rozpisaliśmy w osobnym tekście: ile kosztuje stworzenie aplikacji mobilnej. Wszystkie stawki są w cenniku.

Masz pomysł i kilka szkiców? Zobacz, jak wygląda droga od pomysłu do aplikacji w sklepach. Masz już prototyp albo ekrany w Figmie? Zacznij od swojego prototypu.