Pytanie „ile kosztuje stworzenie MVP?” wygląda jak pytanie o jedną liczbę. W praktyce najpierw trzeba ustalić, co ma powstać.
Dla jednej firmy MVP oznacza jeden działający scenariusz, który można pokazać pierwszym klientom. Dla innej — wersję produkcyjną z kontami użytkowników, płatnościami, panelem administracyjnym i integracjami. Oba projekty noszą tę samą nazwę, ale mają inny zakres, ryzyko i koszt.
Dlatego zamiast rynkowej „średniej ceny MVP” pokazujemy publiczne progi usługi DaVinci: prototyp albo małe narzędzie od 5 000 PLN netto, MVP od 15 000 do 35 000 PLN netto, większy produkt od 35 000 PLN netto oraz opcjonalną analizę za 2 500 PLN netto, odliczaną od budowy rozpoczętej w ciągu 30 dni.
To punkty wejścia do usługi „Zbuduj produkt cyfrowy”, a nie cennik każdej możliwej aplikacji. Końcowa cena wynika z uzgodnionego zakresu, ryzyk i kryteriów odbioru.
użytkownik i cel → działający scenariusz → zakres → cena
Co ma udowodnić pierwsza wersja
MVP nie powinno być przypadkowo pomniejszoną wersją docelowego produktu. Ma umożliwić wykonanie najważniejszego scenariusza od początku do końca i odblokować kolejną decyzję.
Może chodzić o pokazanie rozwiązania potencjalnym klientom, uruchomienie go dla wybranej grupy, obsłużenie pierwszego typu transakcji albo potwierdzenie, że ważna integracja działa. Cel pierwszej wersji wpływa na zakres bardziej niż długa lista funkcji.
Jeżeli potrzebujesz demonstracji na rozmowie z klientem, nie zawsze musisz budować komplet ról, wyjątków i zabezpieczeń wersji produkcyjnej. Jeśli użytkownik ma podać prawdziwe dane lub zapłacić, potrzebujesz elementów zapewniających bezpieczne działanie.
Pierwsze pytanie nie brzmi więc: „Ile ekranów zbudujemy?”, lecz:
Jaką decyzję chcemy podjąć po uruchomieniu tej wersji i co musi zadziałać, żeby ta decyzja była możliwa?
Bez tej odpowiedzi zakres rośnie przy każdej rozmowie. Każda osoba dopisuje funkcję, która „na pewno się przyda”, ale nikt nie potrafi wskazać, czy jest potrzebna do pierwszego użycia.
Jeżeli nie wiesz jeszcze, czy potrzebujesz testu rynku, prototypu czy działającej wersji, zobacz jak zweryfikować pomysł na aplikację lub SaaS.
Prototyp, MVP czy większy produkt
W ofercie DaVinci są trzy warianty. Ich nazwy nie opisują jakości, tylko skalę i cel pierwszego zakresu.
Prototyp albo małe narzędzie
Prototyp służy do pokazania lub sprawdzenia jednego głównego scenariusza. Sprawdza się, gdy trzeba zademonstrować sposób działania, przetestować najbardziej ryzykowny przepływ albo rozwiązać konkretny problem bez budowy rozbudowanej platformy.
Nie powinien udawać pełnego produktu. Przed startem trzeba ustalić, co nadaje się do prawdziwego użycia, a co wyłącznie do demonstracji.
MVP
MVP to pierwsza wersja produkcyjna obejmująca główny przepływ użytkownika, niezbędne role i integracje oraz testy, wdrożenie i przekazanie. Jest właściwe, gdy użytkownik ma wykonać pełne zadanie w działającym środowisku, a produkt po odbiorze ma zostać uruchomiony i dalej rozwijany.
MVP nie oznacza „wszystkiego po trochu”. Dobra pierwsza wersja ma jeden priorytet i świadome granice. Funkcje odłożone na później są częścią decyzji produktowej, a nie brakiem projektu.
Większy produkt
Większy produkt obejmuje więcej ról, procesów lub zależności i wymaga indywidualnej architektury oraz etapowej realizacji. Ma sens, gdy kilka grup użytkowników wykonuje różne zadania, produkt łączy wiele systemów albo uruchamianego zakresu nie da się bezpiecznie ograniczyć do jednego scenariusza.
Większy zakres nie jest automatycznie lepszy. Powinien odpowiadać celowi produktu oraz gotowości firmy do dostarczania danych, podejmowania decyzji i odbierania kolejnych etapów.
Praktyczne kryteria wyboru znajdziesz w poradniku prototyp, MVP czy większy produkt.
Publiczne ceny DaVinci
Poniższe kwoty są publicznymi progami usługi „Zbuduj produkt cyfrowy”. Wszystkie ceny są netto.
| Wariant | Cena netto | Co opisuje |
|---|---|---|
| Opcjonalna analiza i specyfikacja | 2 500 PLN | uporządkowanie przepływu, ryzyk i kryteriów odbioru; kwota odliczana od budowy rozpoczętej w ciągu 30 dni |
| Prototyp albo małe narzędzie | od 5 000 PLN | jeden główny scenariusz i ograniczony zakres, gotowy do pokazania lub testu |
| MVP | 15 000–35 000 PLN | pierwsza wersja produkcyjna z głównym przepływem, potrzebnymi rolami i integracjami, testami, wdrożeniem i przekazaniem |
| Większy produkt | od 35 000 PLN | indywidualna architektura, więcej ról i procesów oraz etapowa realizacja |
Cena „od” nie oznacza, że każda aplikacja zmieści się w najniższym progu. Widełki MVP także nie obiecują, że dowolną listę funkcji da się zrealizować w tym przedziale. Produkt z większą liczbą ról, procesów, integracji albo wymagań technicznych może należeć do wariantu większego produktu.
Końcowa wycena powinna jasno odpowiadać: co powstanie, jakie scenariusze będą działać, co pozostaje poza zakresem, według czego nastąpi odbiór i które koszty zewnętrzne ponosi klient.
Co wpływa na koszt stworzenia MVP
Na koszt wpływają przede wszystkim ryzyko, role użytkowników, integracje i wymagania techniczne. W praktyce warto sprawdzić siedem obszarów.
1. Role i uprawnienia
Produkt dla jednej roli jest zwykle prostszy niż system dla klienta, sprzedawcy, administratora i partnera. Każda rola może wymagać osobnego widoku, danych, uprawnień, powiadomień i reguł dostępu. Koszt rośnie nie przez samą liczbę kont, lecz przez różne zadania i logikę.
2. Kluczowe przepływy
Przepływ to zadanie wykonane od początku do końca: od utworzenia konta do uzyskania rezultatu albo od wystawienia oferty do transakcji. Każdy kolejny przepływ trzeba zaprojektować, opisać, zbudować i przetestować wraz z błędami oraz wyjątkami. Sama liczba ekranów nie pokazuje tej złożoności.
3. Integracje
Płatności, CRM, kalendarz, księgowość, mapy, zewnętrzne dane lub modele AI wymagają więcej niż wpisania klucza API. Trzeba ustalić, jakie dane są wymieniane, które źródło jest nadrzędne, co dzieje się przy błędzie, jak ponowić operację i kto ma dostęp.
4. Dane i migracja
Produkt może startować od pustej bazy albo przejmować użytkowników, dokumenty i historię zdarzeń. Migracja wymaga oceny formatu, kompletności, duplikatów i sposobu kontroli po przeniesieniu. Jeśli dane nie są gotowe, ich przygotowanie powinno być częścią zakresu albo jawnym wyłączeniem.
5. Płatności i rozliczenia
Jednorazowy zakup jest prostszy niż abonament z planami, okresem próbnym, zmianą pakietu, anulowaniem, zwrotami i fakturami. Im więcej reguł rozliczenia, tym więcej stanów trzeba uwzględnić w projekcie i testach.
6. Platformy, bezpieczeństwo i wymagania techniczne
Aplikacja webowa ma inny zakres niż zestaw web, iOS i Android. Demonstrator bez prawdziwych danych wymaga innych zabezpieczeń niż produkt obsługujący płatności i dane klientów. Na koszt wpływają między innymi logowanie, role, historia operacji, kopie zapasowe, monitoring i sposób publikacji na każdej platformie.
7. AI i gotowość decyzji
Funkcja AI potrzebuje konkretnego zadania, danych wejściowych, oczekiwanego wyniku, kontroli błędów i zasad zatwierdzania przez człowieka. Hasło „dodajmy AI” nie jest zakresem.
Koszt tworzy też zmiana założeń podczas budowy: głównego użytkownika, modelu płatności, przepływu albo definicji gotowego rezultatu. Dlatego firma powinna wyznaczyć osobę, która szybko rozstrzyga priorytety i odbiera kolejne elementy.
Co powinna obejmować wycena
Dwie oferty z tą samą ceną mogą obejmować inne rezultaty. Sformułowanie „zbudujemy MVP” nie wystarcza. Dobra wycena powinna wyjaśniać:
| Obszar | Co powinno być jawne |
|---|---|
| Użytkownik i cel | dla kogo powstaje produkt i jakie zadanie umożliwia |
| Przepływy i funkcje | co działa od początku do końca, co wchodzi teraz, a co później |
| Role i integracje | kto korzysta z produktu, z czym system się łączy i w jakim zakresie |
| Dane | kto je dostarcza i czy potrzebna jest migracja |
| UX, UI i platformy | jaki projekt interfejsu oraz środowiska obejmuje cena |
| Testy i wdrożenie | co zostanie sprawdzone oraz gdzie produkt będzie uruchomiony |
| Przekazanie | jakie prawa, repozytorium, konta, dane i dokumentacja trafią do klienta |
| Odbiór i wyłączenia | po czym zakres zostanie uznany za wykonany i czego cena nie obejmuje |
| Dalszy rozwój | co dzieje się po odbiorze pierwszej wersji |
Im dokładniej oferta opisuje rezultat i granice, tym łatwiej porównać cenę bez dopowiadania sobie zakresu.
Koszty poza wyceną wykonawcy
Koszt budowy nie zawsze jest pełnym kosztem uruchomienia i posiadania produktu. Warto oddzielić wydatki jednorazowe, stałe oraz zmienne, rosnące wraz z użyciem.
Licencje, infrastruktura i zużycie
Produkt może korzystać z płatnych usług do wysyłki wiadomości, płatności, przechowywania plików, analityki, map, monitoringu, podpisu elektronicznego, modeli AI lub danych zewnętrznych. Potrzebne mogą być też domena, hosting, baza danych, środowisko testowe i kopie zapasowe.
Trzeba ustalić, kto zakłada konta, do kogo należą i według czego dostawca nalicza opłaty. Część usług rozlicza użytkowników, inne operacje, transakcje, dane lub faktyczne zużycie. Aktualne warunki konkretnego dostawcy trzeba sprawdzić przed startem.
Dane, treści i wymagania branżowe
Kod nie tworzy opisów, regulaminu, polityki prywatności, zdjęć, katalogu ofert ani danych startowych. Brak tych materiałów może zatrzymać uruchomienie mimo zakończonej budowy.
W zależności od produktu firma może też potrzebować własnej analizy prawnej, dokumentów, oceny zgodności lub dodatkowego audytu. Ogólna wycena budowy nie jest automatycznym potwierdzeniem zgodności prawnej.
Czas zespołu klienta
Po stronie firmy ktoś musi dostarczyć dane i dostępy, podejmować decyzje, uczestniczyć w prezentacjach, testować i odbierać rezultat. Gdy nie ma właściciela decyzji, rośnie nie tylko czas projektu, lecz także ryzyko budowy według nieaktualnych założeń.
Utrzymanie, rozwój i marketing
Po uruchomieniu mogą pojawić się aktualizacje zależności, zmiany integracji, monitoring, reakcja na incydenty, nowe funkcje i wsparcie operacyjne. Powinny być wycenione osobno albo objęte dalszym modelem współpracy.
Działający produkt nie gwarantuje popytu, użytkowników ani przychodu. Marketing, sprzedaż i budżet reklamowy również nie są domyślnie częścią ceny budowy MVP.
Przed podpisaniem oferty warto uzupełnić prostą kartę kosztów:
| Pozycja | Jednorazowa / stała / zmienna | Kto płaci | Czy jest w wycenie |
|---|---|---|---|
| Licencje, hosting i baza danych | ___ | ___ | tak / nie |
| Wiadomości, płatności, AI lub dane | ___ | ___ | tak / nie |
| Migracja, treści i dokumenty | ___ | ___ | tak / nie |
| Testy lub audyty dodatkowe | ___ | ___ | tak / nie |
| Utrzymanie i dalszy rozwój | ___ | ___ | tak / nie |
| Marketing i pozyskanie użytkowników | ___ | ___ | tak / nie |
Puste pole nie oznacza braku kosztu. Oznacza, że trzeba go sprawdzić przed decyzją.
Stała cena i analiza przed budową
Stała cena dotyczy ustalonego zakresu i kryteriów odbioru. Powinna oznaczać, że obie strony wiedzą, co zostanie zbudowane, jakie scenariusze mają działać, co jest wyłączone i jak nastąpi odbiór. Zmiana zakresu jest osobną decyzją wpływającą na cenę lub harmonogram.
Nie oznacza to dowolnego dopisywania funkcji, zmiany użytkownika lub modelu produktu bez wpływu na wycenę ani ciągłego rozwoju po uruchomieniu. Gdy zakres może zmieniać się bez konsekwencji, ryzyko nie znika — trafia do niejasnych zapisów i późniejszych sporów.
Opcjonalna analiza i specyfikacja pomagają, gdy:
- brakuje jednego głównego przepływu lub kryteriów odbioru;
- kilka grup użytkowników ma różne potrzeby;
- nie wiadomo, co musi wejść do pierwszej wersji;
- integracja lub dane mogą zmienić sposób budowy;
- ryzyko nie pozwala jeszcze odpowiedzialnie podać stałej wyceny.
W ramach analizy porządkowane są przepływ, ryzyka, architektura i kryteria potrzebne do wyceny. Cena wynosi 2 500 PLN netto i jest odliczana od budowy rozpoczętej w ciągu 30 dni.
Analiza nie jest obowiązkowa. Jeżeli firma potrafi wskazać użytkownika, problem, cel, właściciela decyzji i wystarczająco jasny zakres, można przejść bezpośrednio do wyceny.
Jak przygotować zakres i porównać oferty
Do pierwszej wyceny nie potrzebujesz kompletnej specyfikacji. Przygotuj:
- Użytkownika i problem: kto ma wykonać najważniejsze zadanie, jak robi to dzisiaj i dlaczego obecny sposób nie wystarcza.
- Cel biznesowy i następną decyzję: po co firma uruchamia produkt i co chce wiedzieć po starcie pierwszej wersji.
- Główny scenariusz: co użytkownik robi od wejścia do rezultatu, krok po kroku.
- Role, integracje i dane: kto jeszcze korzysta z systemu, z czym ma się łączyć i jakie materiały już istnieją.
- Właściciela decyzji i granice: kto rozstrzyga zakres oraz co musi działać teraz, może wejść później i nie wchodzi do projektu.
Następnie zadaj każdemu wykonawcy te same pytania:
- Jaki dokładnie przepływ będzie działał po odbiorze?
- Które funkcje, role, platformy, UX i interfejs są w cenie?
- Co wyłączono z zakresu?
- Kto odpowiada za integracje, dane i migrację?
- Jakie testy i wdrożenie obejmuje oferta?
- Jakie prawa, repozytorium, konta, dane i dokumentację otrzyma klient?
- Jakie opłaty zewnętrzne pozostają po stronie klienta?
- Co dzieje się przy niespełnieniu kryteriów albo zmianie zakresu?
- Czy utrzymanie i dalszy rozwój są w cenie?
Najniższa oferta może dotyczyć prototypu, gdy inna obejmuje wersję produkcyjną. Najwyższa może zawierać elementy, których firma teraz nie potrzebuje. Porównuj najmniejszy zakres, który osiąga cel bez ukrywania ryzyk.
Cena MVP zaczyna się od decyzji o zakresie
Koszt stworzenia MVP aplikacji lub SaaS wynika z użytkownika, przepływu, ról, integracji, danych, wymagań technicznych, sposobu wdrożenia i kryteriów odbioru.
Publiczne ceny DaVinci porządkują trzy poziomy: prototyp albo małe narzędzie od 5 000 PLN netto, MVP od 15 000 do 35 000 PLN netto oraz większy produkt od 35 000 PLN netto. Gdy założenia są zbyt niejasne, opcjonalna analiza kosztuje 2 500 PLN netto i jest odliczana od budowy rozpoczętej w ciągu 30 dni.
Cena jest ważna. Jeszcze ważniejsze jest to, czy po odbiorze firma dostanie wersję, która pozwala wykonać najważniejszy scenariusz i podjąć kolejną decyzję na podstawie działania, a nie wyobrażenia.