Ile kosztuje MVP aplikacji i co powinno się w nim znaleźć

Czym jest MVP, a czym na pewno nie jest

MVP nie jest wersją uboższą i nie jest prototypem do wyrzucenia. To najmniejszy wycinek produktu, który realnie załatwia jedną sprawę i który można postawić przed człowiekiem z zewnątrz.

Kryterium nie jest liczba funkcji, tylko to, czy ktoś spoza zespołu wykona za pomocą aplikacji całe zadanie, od pierwszego kliknięcia do rezultatu, którego oczekiwał. Jeśli musisz stać obok, poprawić coś w bazie albo dosłać brakujący plik mailem, to jeszcze nie MVP, tylko pokaz.

Najdroższy wariant to wersja uboga, czyli pełna lista funkcji wykonana po łebkach. Trzy rzeczy działające do połowy uczą mniej niż jedna działająca w całości, bo użytkownik odchodzi i nie wiadomo, czy odszedł przez pomysł, czy przez usterkę. Cięcie ma polegać na wyrzucaniu funkcji, nie na obniżaniu jakości tych, które zostają.

Prototyp odpowiada na inne pytanie. Klikalne makiety pokazują w kilka dni, czy układ jest zrozumiały, ale nie powiedzą, czy ktoś wróci jutro i wpisze prawdziwe dane swojej firmy. Warto też odrzucić myśl, że pierwszą wersję i tak się potem przepisze: kod, na którym ktoś zaczyna pracować, zostaje na lata, bo po pierwszych klientach nie ma dobrego momentu na przerwę.

• MVPJedna ścieżka doprowadzona do końca, z prawdziwym kontem i prawdziwymi danymi. Osoba z zewnątrz kończy zadanie bez Twojej pomocy i bez instrukcji na komunikatorze.
• PrototypKlikalna makieta bez danych i bez zaplecza. Sprawdza zrozumiałość interfejsu, a nie gotowość do zapłaty ani powrót po tygodniu.
• Wersja ubogaCała wymarzona lista funkcji, każda wykonana pobieżnie. Kosztuje tyle co porządne MVP i nie odpowiada na żadne pytanie, bo każda porażka ma kilka możliwych przyczyn.

Jak wybrać jedną funkcję, która ma działać naprawdę

Zakres ustala się od strony zadania użytkownika, nie od strony listy życzeń. Pomaga jedno pytanie: co ta osoba robi dzisiaj zamiast tego i ile ją to kosztuje.

Dwa błędy powtarzają się częściej niż pozostałe. Pierwszy to wybór funkcji najciekawszej technicznie zamiast najbardziej dotkliwej; poznasz go po tym, że trudno wytłumaczyć, komu konkretnie ona pomaga. Drugi to rozbudowane role i panel administracyjny, które zjadają połowę budżetu, zanim ktokolwiek zobaczy to, po co przyszedł. Na starcie wystarczą zwykle dwie role: ten, kto wykonuje zadanie, i ten, kto ma podgląd. Dopisanie trzeciej do gotowego modelu uprawnień jest tanie, projektowanie sześciu na zapas kosztuje tygodnie.

1. Nazwij zadanie, nie funkcjęNie „panel z raportami”, tylko „kierownik zmiany o szóstej rano wie, kto nie przyszedł do pracy”. Lista funkcji spisana przed zadaniem prawie zawsze opisuje cudzy produkt.
2. Opisz obecny sposób pracyArkusz, grupa na komunikatorze, telefon do biura. To jest Twoja prawdziwa konkurencja i to ona wyznacza poprzeczkę. Aplikacja tylko trochę lepsza od arkusza przegra z przyzwyczajeniem.
3. Znajdź miejsce, w którym boliZwykle jest jedno: moment, w którym ktoś przepisuje dane z miejsca w miejsce, czeka na odpowiedź albo szuka informacji, która gdzieś już jest. Ten moment jest całym zakresem pierwszej wersji.
4. Wytnij wszystko, co da się zrobić ręcznieKonta zakładane na prośbę mailową, faktury wystawiane w zwykłym programie, dane wgrywane plikiem raz dziennie. Ręczna obsługa kilkudziesięciu osób jest tańsza niż oprogramowanie jej.
5. Przejdź ścieżkę na kartceKrok po kroku, od wejścia do rezultatu. Każde miejsce, w którym musisz dopisać „a potem ja to robię”, jest albo świadomą decyzją na pierwsze tygodnie, albo dziurą, przez którą użytkownik wypadnie.

Widełki kosztu MVP w Polsce i od czego zależą

Publiczne cenniki polskich wykonawców rozjeżdżają się mocniej niż w innych usługach, bo każdy nazywa MVP czymś innym. Przedział bez opisu zakresu nie znaczy nic.

Dolny koniec zaczyna się niżej, niż sugerują teksty o start-upach. MZSoft podaje 12 000–25 000 zł za MVP z logowaniem, wdrożeniem produkcyjnym i wsparciem po starcie w 4–8 tygodni, a za sam klikalny prototyp 5 000–10 000 zł w 2–4 tygodnie. Środek rynku widać w cennikach rozpisanych na poziomy: JSON Crew podaje 15 000–30 000 zł za jedną ścieżkę z jedną lub dwiema integracjami, 30 000–50 000 zł za dwie lub trzy ścieżki z rolami oraz 50 000–90 000 zł za wersję obsługującą wielu klientów w jednej instancji. Górny koniec podaje ATCsc: 30 000–200 000 zł przy czasie 6–16 tygodni.

Różnica między końcami tych widełek jest szesnastokrotna, więc sam przedział nie jest informacją. Informacją jest to, co przesuwa wycenę, a przesuwają ją trzy rzeczy i żadna nie jest liczbą ekranów. Role i uprawnienia, bo każda kolejna mnoży liczbę przypadków do przetestowania. Integracje z cudzymi systemami, bo nie kontrolujesz ich awarii ani zmian. Płatności, które wciągają fakturowanie, zwroty i reklamacje, czyli trzy tematy w cenie jednego.

Stawki godzinowe pozwalają sprawdzić, czy wycena w ogóle się spina. MZSoft podaje 100–180 zł netto za godzinę dla małych studiów, 150–250 zł dla agencji i 80–150 zł dla freelancerów. JSON Crew podaje dla Warszawy 170–220 zł u seniora i 105–150 zł u osoby średnio doświadczonej. Wycena na 20 000 zł przy stawce 150 zł to mniej więcej 130 godzin, czyli miesiąc pracy jednej osoby; jeśli zakres wygląda na trzy miesiące, liczby się nie zgadzają i ktoś dopłaci różnicę jakością.

Licz pierwszy rok, nie sam start. JSON Crew podaje 70 000–80 000 zł jako łączny koszt pierwszego roku dla projektu ze środkowego poziomu, razem z iteracjami po starcie i hostingiem, a weBites szacuje wsparcie po wdrożeniu na 15–25% rocznej wartości projektu. Budżet kończący się w dniu uruchomienia zwykle oznacza produkt porzucony w trzecim miesiącu.

Wszystkie liczby w tej sekcji to stan na 19 września 2026 r. i pochodzą z publicznych materiałów wykonawców, którzy zmieniają je bez zapowiedzi. Traktuj je jako punkt odniesienia do rozmowy i potwierdź aktualne widełki wprost u wykonawcy, któremu zamierzasz zlecić pracę.

Ceny i stawki sprawdzone 19 września 2026. Dostawcy zmieniają cenniki, więc przed decyzją sprawdź aktualną kwotę u źródła.

Co można odłożyć na później, a czego nie wolno

Cięcie zakresu jest sensem MVP. Kłopot zaczyna się wtedy, gdy zamiast funkcji obcina się rzeczy, których brak wychodzi dopiero przy awarii albo przy pierwszym pytaniu o dane osobowe.

Zasada jest prosta: odkładaj wygodę, nie odkładaj odpowiedzialności. Brak wyszukiwarki denerwuje, brak kopii zapasowej kończy projekt, a brak podstaw prawnych zamienia udany test w kłopot trwający dłużej niż sam produkt. Wymienione wyżej obowiązki i terminy potwierdź w aktualnym tekście rozporządzenia, bo przepisy zmieniają się niezależnie od Twojego harmonogramu.

• Można odłożyć: panel administracyjnyPrzez pierwsze tygodnie zmiany w danych robi się wprost w bazie albo prostym skryptem. Panel powstaje wtedy, gdy ma z niego korzystać ktoś inny niż Ty, i wtedy wiadomo już, jakie operacje są naprawdę potrzebne.
• Można odłożyć: samodzielna rejestracjaKonta zakładane ręcznie po mailu działają spokojnie do kilkudziesięciu osób i wymuszają kontakt z każdym nowym użytkownikiem, co na tym etapie jest cenniejsze niż formularz.
• Można odłożyć: wyszukiwarka, eksport, powiadomieniaPrzy kilkudziesięciu rekordach wyszukiwarka jest ozdobą, eksport zastępuje zapytanie do bazy, a powiadomienia wyślesz osobiście. Wrócą, gdy dane urosną, i wtedy będzie wiadomo, jak mają wyglądać.
• Nie wolno: kopie zapasowe i test odtworzeniaKopia, której nikt nigdy nie odtworzył, nie jest kopią, tylko plikiem. Utrata danych pierwszych użytkowników kończy produkt, bo ci ludzie nie wrócą. Odtworzenie na czystym środowisku zajmuje jedno popołudnie.
• Nie wolno: podstawy ochrony danychPodstawa prawna przetwarzania, informacja dla użytkownika, umowy powierzenia z dostawcami i rejestr czynności obowiązują od pierwszego prawdziwego konta. Naruszenie zgłasza się organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości nie później niż w terminie 72 godzin po stwierdzeniu, zgodnie z art. 33 ust. 1 RODO, stan na 19 września 2026 r.
• Nie wolno: logi i czytelne błędyBez zapisu zdarzeń po stronie serwera pierwsza usterka zgłoszona zdaniem „nie działa” jest nie do odtworzenia. Potrzebujesz identyfikatora błędu widocznego dla użytkownika i tego samego identyfikatora w logu, z czasem i kontekstem operacji.
• Nie wolno: rzetelna obsługa płatnościGdy MVP przyjmuje pieniądze, przestaje być eksperymentem. Potwierdzenie płatności musi przychodzić do serwera od operatora, dokument sprzedaży ma powstawać dokładnie raz, a procedura zwrotu musi istnieć przed pierwszą reklamacją.

No-code na start: kiedy się opłaca, a kiedy trzeba pisać od nowa

Narzędzia no-code wygrywają czasem do pierwszych użytkowników i przegrywają wszędzie tam, gdzie produkt wychodzi poza to, co przewidział ich autor.

Zestaw, który najczęściej ma sens, to baza danych i gotowy interfejs nad nią: Airtable jako tabele plus Softr jako aplikacja dla użytkowników, albo Bubble jako jedno narzędzie do wszystkiego. W kilka dni masz logowanie, listy, formularze i widok dla klienta. Dla narzędzia wewnętrznego albo usługi, której proces mieści się w tabelach, to zwykle najszybsza droga do prawdziwych danych.

Ceny są jawne i rosną skokami. Bubble ma plan darmowy z 50 tys. jednostek pracy miesięcznie, Starter za 59 USD miesięcznie przy rozliczeniu rocznym ze 175 tys. jednostek, Growth za 209 USD i Team za 549 USD. Airtable kosztuje 20 USD za użytkownika miesięcznie w planie Team i 45 USD w Business przy rozliczeniu rocznym, a limit rekordów w jednej bazie wynosi 1 000 w planie darmowym, 50 000 w Team i 125 000 w Business. Softr daje plan darmowy z pięcioma użytkownikami aplikacji i 5 tys. rekordów, Basic za 19 USD miesięcznie, Professional za 99 USD i Business za 329 USD.

Problem z tymi cennikami nie polega na wysokości kwot, tylko na tym, za co liczą. Jednostki pracy i miejsca dla użytkowników rosną razem z sukcesem, a nie razem z zakresem, więc rachunek podnosi się dokładnie wtedy, gdy produkt zaczyna działać. Twardsza granica jest jednak funkcjonalna: nietypowy model uprawnień liczony na poziomie rekordu, szybkie wyszukiwanie po dużym zbiorze, integracja wymagająca kolejki i ponawiania nieudanych prób, praca wykonywana w tle nocą. Jeśli choć jedna z tych rzeczy jest sednem produktu, no-code odłoży problem, ale go nie rozwiąże.

Migracja nie jest przeniesieniem, tylko napisaniem produktu od nowa. Dane wyeksportujesz bez trudu, natomiast reguły, automatyzacje i układ ekranów są zapisane w formacie platformy i nie mają postaci, którą dałoby się przenieść. Zostaje sprawdzona specyfikacja, bo wiesz już dokładnie, co produkt ma robić. To sporo, ale płaci się za to drugim wdrożeniem.

Dla porównania własne zaplecze kosztuje dziś mniej, niż wielu osobom się wydaje. Render rozlicza przestrzeń roboczą osobno od mocy obliczeniowej: plan Hobby to 0 USD miesięcznie plus moc, plan Pro 25 USD plus moc, pojedyncza usługa webowa zaczyna się od 7 USD miesięcznie za 512 MB pamięci i 25 USD za 2 GB, a baza PostgreSQL od 6 USD za 256 MB i 19 USD za 1 GB. Vercel ma plan Hobby za 0 USD i Pro za 20 USD miesięcznie za miejsce, z wliczonym kredytem 20 USD na zużycie zasobów. Wszystkie ceny w tej sekcji to stan na 19 września 2026 r.; dostawcy zmieniają cenniki i limity kilka razy w roku, więc przed policzeniem budżetu potwierdź każdą kwotę na stronie producenta.

Ceny i stawki sprawdzone 19 września 2026. Dostawcy zmieniają cenniki, więc przed decyzją sprawdź aktualną kwotę u źródła.

Jak zmierzyć, czy MVP zadziałał

Liczba rejestracji nie mówi nic poza tym, ile osób kliknęło w link. Mówi to, czy ktoś dokończył zadanie i czy wrócił po nie drugi raz.

Próg ustala się przed startem, jednym zdaniem, w którym są konkretne osoby i konkretny termin. Na przykład: w ciągu ośmiu tygodni dwadzieścia osób spoza kręgu znajomych dokończy zadanie, a połowa z nich wróci w kolejnym tygodniu. Bez takiego zdania zawsze znajdzie się powód, żeby dołożyć jeszcze jedną funkcję i przesunąć ocenę o miesiąc.

Pomiar musi zapisywać się po stronie serwera, w chwili faktycznego ukończenia zadania, a nie kliknięcia przycisku. Kliknięcie oznacza chęć, ukończenie oznacza wartość. Jedno zdarzenie zapisane porządnie jest warte więcej niż rozbudowana analityka nałożona na produkt, którego nikt jeszcze nie używa.

Najcenniejsze są rozmowy z osobami, które przestały korzystać. Pięć takich rozmów daje więcej niż pięćdziesiąt ankiet, bo powód rezygnacji zwykle brzmi banalnie: nie wiedziałem, co zrobić dalej, było szybciej po staremu, nie miałem pod ręką danych, których wymagał formularz.

• Dokończone zadania, nie rejestracjeLicz ludzi, którzy doszli do rezultatu. Rejestracja bez ukończonego zadania oznacza zwykle, że ścieżka jest dłuższa niż cierpliwość użytkownika.
• Powrót w kolejnym tygodniuPierwsze wejście mówi o obietnicy, drugie o produkcie. Jeżeli nikt nie wraca, kolejne funkcje tego nie zmienią.
• Czas od wejścia do rezultatuPorównaj go z czasem, jakiego wymaga obecny sposób pracy. Produkt wolniejszy od arkusza nie wygra żadną funkcją.
• Uwaga na życzliwychZnajomi zawsze dokończą zadanie i zawsze pochwalą pomysł. Do progu liczą się wyłącznie osoby, które nie mają wobec Ciebie żadnego zobowiązania.

Co robić po pierwszych użytkownikach

Po starcie lista zgłoszeń rośnie szybciej niż zdolność ich obsługi. Wtedy potrzebna jest już nie wizja, tylko kolejność.

Zgłoszenia dzielą się na trzy kubły i tylko jeden jest pilny. Pierwszy: to blokuje wykonanie zadania. Drugi: to spowalnia, ale da się obejść. Trzeci: to życzenie, często opisujące narzędzie, którego ktoś używał wcześniej. Pierwszy kubeł ma zawsze pierwszeństwo, a trzeci warto zostawić na liście i sprawdzić po miesiącu, czy nadal ktoś o to prosi.

Nie rozbudowuj wszerz, zanim jedna ścieżka nie działa dla wszystkich. Druga rola, drugi typ klienta i druga integracja to w praktyce trzy osobne produkty. Długu technicznego z MVP nie spłaca się w całości, tylko w trzech miejscach: testy najważniejszej ścieżki, oprogramowanie czynności robionych ręcznie w kolejności od najczęstszej oraz monitoring z powiadomieniem, żebyś o awarii dowiadywał się przed użytkownikiem.

Osobną sprawą jest uczciwe przyznanie, że nie zadziałało. Jeżeli próg się nie wypełnił, a rozmowy pokazują, że ludzie nie mają problemu, który założyłeś, najtańszą decyzją jest zatrzymanie prac. MVP kosztowało wtedy dokładnie tyle, ile miało kosztować, i oszczędziło budżet pełnego produktu, którego nikt by nie kupił. To jest sukces tej metody, a nie jej porażka.

Ja zaczynam od rozpisania jednego zadania użytkownika i od tego, co da się z niego wyciąć bez utraty sensu, dopiero potem rozmawiamy o technologii. Buduję aplikacje webowe w Angularze albo w React z Next.js, z logiką w TypeScript i danymi w PostgreSQL, więc pierwsza wersja jest zwykle tą samą, którą później się rozwija, a nie osobnym bytem do wyrzucenia. Pracuję jednoosobowo, z Mikołowa, zdalnie w całej Polsce; jeśli chcesz przejść przez zakres, napisz, co Twoi użytkownicy robią dziś zamiast tego.

Pytania i odpowiedzi