Krótka odpowiedź: prosty MVP aplikacji webowej da się zbudować i wdrożyć w 2 do 4 tygodni. Warunek: jeden problem, jedna grupa użytkowników i jedna główna ścieżka w aplikacji. Najwięcej czasu traci się nie na programowaniu, tylko na dokładaniu funkcji, których nikt jeszcze nie potrzebuje. Tnij zakres, wdrażaj wcześnie, pokaż produkt ludziom.
Aktualizacja: 1 października 2026 r.
Niżej porównuję trzy sposoby budowy MVP, rozpisuję kroki od pomysłu do pierwszych użytkowników i pokazuję dwa produkty, które zbudowałem od zera: Stadomat, cyfrową księgę stada, zbudowaną w 9 dni, i KOWiR, portal szkoleń AI.
Czym MVP jest, a czym nie jest
MVP to najmniejsza wersja produktu, która rozwiązuje prawdziwy problem prawdziwego użytkownika od początku do końca. Nie jest makietą ani prezentacją. Działa w sieci, ktoś może się zarejestrować i zrobić to, po co przyszedł.
MVP nie jest też „wersją pierwszą z połową funkcji”. Jeśli planujesz dziesięć funkcji i robisz pięć, to nadal jest za dużo. Lepiej zrobić jedną rzecz tak dobrze, żeby użytkownik wrócił, niż pięć, z których żadna nie działa do końca.
Trzy sposoby budowy MVP: porównanie
| Sposób | Kiedy pasuje | Mocna strona | Na co uważać |
|---|---|---|---|
| Narzędzie no-code | Chcesz sprawdzić zainteresowanie, logika jest prosta, sam chcesz klikać | Najszybsza pierwsza wersja, bez programisty | Limity platformy, koszty rosną z liczbą użytkowników, przejście na własny kod zwykle oznacza budowę od nowa |
| MVP w kodzie u jednego wykonawcy | Wiesz, jaki problem rozwiązujesz, i chcesz produkt, który da się rozwijać | Krótki czas, jedna osoba odpowiada za całość, kod i konta są Twoje | Zakres musi być naprawdę mały, a decyzje szybkie |
| Software house | Duży, dobrze opisany projekt, wiele ról w zespole, wymagania zgodności | Zespół, procesy, dokumentacja | Dłuższy start i wyższy koszt, co przy niesprawdzonym pomyśle oznacza duże ryzyko |
Szersze porównanie z perspektywy założyciela jest w artykule MVP w tydzień czy software house.
Krok po kroku: od pomysłu do pierwszych użytkowników
- Zapisz problem w jednym zdaniu. Kto ma problem, jaki i kiedy go odczuwa. Na przykład: hodowca bydła musi zgłaszać zdarzenia do ARiMR w terminie, a prowadzi księgę stada w zeszycie.
- Porozmawiaj z kilkoma osobami, które mają ten problem. Zanim powstanie pierwsza linia kodu. To najtańszy moment, żeby odkryć, że problem wygląda inaczej, niż myślisz.
- Wybierz jedną główną ścieżkę. Rejestracja, główna czynność, efekt. W Stadomacie: podajesz numer sztuki albo skanujesz kolczyk i widzisz jej historię oraz status zgłoszenia.
- Spisz listę „nie teraz”. Wszystko, co kusi, ale nie jest potrzebne do pierwszego użycia. Ta lista chroni termin bardziej niż jakikolwiek harmonogram.
- Zaprojektuj dane, potem ekrany. Dobrze ułożona baza danych sprawia, że kolejne funkcje dokłada się łatwo. Źle ułożona sprawia, że każda zmiana boli.
- Wdrażaj na produkcję wcześnie. Produkt powinien działać pod prawdziwym adresem już w trakcie budowy, a nie dopiero ostatniego dnia. Wtedy ostatni tydzień to poprawki, a nie gaszenie pożarów.
- Daj produkt pierwszym użytkownikom. Obserwuj, gdzie się gubią i czego szukają. Jedna rozmowa z użytkownikiem przy ekranie mówi więcej niż tydzień planowania.
- Zdecyduj, co dalej. Rozwijać, zmienić kierunek albo zamknąć. Każda z tych decyzji jest dobra, jeśli opiera się na reakcjach ludzi, a nie na przeczuciu.
Dlaczego 2 do 4 tygodni jest realne
Kilka lat temu taki termin byłby trudny dla jednej osoby. Dziś pomagają w tym trzy rzeczy: gotowe usługi do logowania, płatności i baz danych, nowoczesne frameworki webowe i asystent AI do programowania, który przyspiesza pisanie i sprawdzanie kodu. Przy Stadomacie używałem Next.js, PostgreSQL i Claude Code jako wsparcia w programowaniu.
Ale narzędzia nie zastąpią decyzji. Termin dowozi się cięciem zakresu, a nie szybszym pisaniem. Jeśli w połowie projektu pojawia się „jeszcze tylko jedna funkcja”, trafia na listę „nie teraz”.
Przykład 1: Stadomat, cyfrowa księga stada w 9 dni
Hodowca bydła prowadzi księgę stada i zgłasza zdarzenia do ARiMR. Na papierze łatwo o pomyłkę i spóźnienie, a za spóźnione zgłoszenie grożą kary. Trzeba było zamienić zeszyt i ręczne liczenie dni w coś, co rolnik obsłuży z telefonu w oborze.
Pierwsza wersja Stadomatu powstała w 9 dni: najpierw rozmowy z hodowcami i projekt bazy danych, potem aplikacja i główne funkcje, na końcu integracje, testy, wdrożenie i poprawki. Efekt: cała obora w telefonie, przypomnienie o terminie siedmiu dni na zgłoszenie do ARiMR, rejestracja konta w minutę bez karty i eksport danych hodowcy do pliku. Opis jest w case study cyfrowej księgi stada.
Przykład 2: KOWiR, portal szkoleń AI
Urzędy, szkoły i firmy chcą wejść w AI, ale nie wiedzą, od czego zacząć. KOWiR zbiera w jednym portalu szkolenia, wdrożenia, narzędzia, bazę wiedzy i finansowanie. Wejście jest przez konkret: bezpłatny cykl z gotowym skryptem do pracy. Portal od pierwszego dnia ma zapis, konto uczestnika, koszyk i płatne szkolenia, więc mógł zacząć zbierać zapisy od razu. Szczegóły są w case study KOWiR.
Ile to kosztuje
Rynkowe widełki i to, z czego składa się cena, rozpisałem w artykule ile kosztuje MVP w Polsce. U mnie Szybki start produktu to działający produkt wdrożony w sieci w 2 do 4 tygodni, od 15 000 PLN netto. Kod i konta są Twoje, a przez dwa tygodnie po starcie poprawiam błędy i wprowadzam drobne zmiany. Jeśli nie wiesz, czy Twój pomysł mieści się w takim zakresie, umów bezpłatną rozmowę. Opowiesz, co chcesz zrobić, a ja powiem, co da się wyciąć, żeby zdążyć.
Najczęstsze pytania
Ile trwa zrobienie MVP aplikacji?
Prosty MVP aplikacji webowej, skupiony na jednym problemie i jednej grupie użytkowników, da się zbudować i wdrożyć w 2 do 4 tygodni. Dłużej trwa wtedy, gdy zakres rośnie w trakcie albo gdy produkt wymaga wielu integracji z zewnętrznymi systemami.
Ile kosztuje MVP?
To zależy od zakresu i wykonawcy. U mnie Szybki start produktu, czyli działający produkt wdrożony w 2 do 4 tygodni, kosztuje od 15 000 PLN netto, razem z dwoma tygodniami wsparcia po starcie. Szczegółowe rozbicie kosztów rynkowych opisałem w osobnym artykule.
Czy MVP można zrobić w narzędziu no-code?
Tak, jeśli chcesz sprawdzić, czy ktoś w ogóle chce Twojego rozwiązania, a logika jest prosta. No-code bywa najszybszą drogą do pierwszej wersji. Gorzej, gdy produkt ma rosnąć: przeniesienie z no-code do własnego kodu często oznacza budowanie od nowa.
Co musi mieć MVP, a co może poczekać?
MVP musi rozwiązywać jeden problem od początku do końca dla jednej grupy użytkowników: rejestracja, główna czynność i jej efekt. Panel administracyjny z wieloma opcjami, rozbudowane raporty, kolejne role i integracje mogą poczekać, aż pierwsi użytkownicy pokażą, czego naprawdę potrzebują.
Czy kod MVP będzie mój?
Powinien. Zanim podpiszesz umowę, sprawdź, czy dostajesz kod, dostęp do serwera i konta usług na siebie. W Szybkim starcie produktu kod i konta są Twoje, bez uzależnienia od jednej firmy.
Co zrobić po wdrożeniu MVP?
Dać produkt pierwszym użytkownikom, zebrać ich reakcje i zdecydować, co budować dalej, zamiast zgadywać. Jeśli produkt się przyjmuje, rozwój można kontynuować w stałym rytmie, na przykład w modelu opieki na abonament.