Od pomysłu do działającego MVP w jeden weekend: mój proces vibecodingu dla founderów

Robiłem to wystarczająco wiele razy, żeby przestać to romantyzować. „MVP w weekend” brzmi jak hasło z konferencji, ale stoi za nim całkiem przyziemny, powtarzalny proces. Sam buduję produkty z AI — dla Dronehuba, dla Oswin AI, dla własnych narzędzi wewnętrznych — i uczę tego founderów pod markami VADYM.AI oraz polską KIERUNEK.AI, którą współtworzę z Instytutem Kryptografii. Poniżej więc nie motywacja, tylko playbook. Co realnie zdążysz w dwa dni, czego nie, gdzie wykłada się 90% prób i jak wygląda moja checklista na sobotę i niedzielę.

Od razu ustalmy rzecz najważniejszą. „Działające MVP w weekend” to nie mała wersja skomplikowanego produktu. To pełna wersja bardzo małego produktu. Cała różnica między tymi dwoma zdaniami i jest tym artykułem.

Krok 0: uczciwie o granicach weekendu

Zanim cokolwiek zbudujesz, musisz wiedzieć, w co grasz. Karpathy, który wprowadził termin „vibecoding” w lutym 2025, uczciwie opisał go jako tryb właśnie do „jednorazowych projektów na weekend” — szybkich, beztroskich, w których nie czytasz każdej linijki kodu. To idealny opis tego, co robimy w sobotę i niedzielę, a zarazem ostrzeżenie.

Oto uczciwa granica, którą trzymam w głowie:

Jeśli trzymasz tę granicę, weekend kończy się działającym produktem. Jeśli ją zignorujesz — kończy się na wpół złożonym systemem, którego się wstydzisz i którego szkoda wyrzucić.

Krok 1: zawęź pomysł do jednego bólu (sobota, rano)

Najdroższy błąd zdarza się jeszcze przed pierwszą linijką kodu — na poziomie sformułowania. Founder przychodzi z pomysłem o rozmachu „platforma do X”. Platformy w weekend nie zrobisz, więc albo zawęzisz pomysł sam, albo rzeczywistość zawęzi go za ciebie, ale już o drugiej w nocy w niedzielę i boleśnie.

Moja zasada: dopóki nie umiesz ująć bólu w jednym zdaniu o jednym człowieku, na budowanie jest za wcześnie. Nie „aplikacja dla restauracji”, tylko „kelner w dziesięć sekund widzi, których dań dziś nie ma w karcie”. Nie „CRM dla coachów”, tylko „coach jednym kliknięciem wysyła klientowi przypomnienie o jutrzejszej sesji”.

Zadaję sobie trzy pytania i wymagam odpowiedzi w jednym zdaniu:

• Kto to konkretny człowiek? (nie „firmy”, tylko „Maria, recepcjonistka salonu”)
• Który jeden moment w jej dniu teraz boli? (nie „nieefektywność”, tylko „ręcznie przepisuje zapisy z trzech komunikatorów do zeszytu”)
• Jak wygląda ulga? (nie „optymalizacja”, tylko „wszystkie zapisy na jednej liście, która odświeża się sama”)

Jeśli na te trzy pytania nie ma krótkich odpowiedzi — to nie jest zadanie na weekend, to zadanie na jeszcze jeden dzień przemyśleń. Pół godziny tutaj oszczędza pół dnia zamętu później. Tej pół godziny nigdy nie żałowałem.

Krok 2: wytnij najmniejszy użyteczny kawałek (sobota, rano)

Teraz z jednego bólu trzeba wyciąć najmniejszy kawałek, który już daje korzyść. Po angielsku nazywa się to MVP — minimum viable product — i kluczowe słowo to nie „minimum”, tylko „viable”: zdolny do życia. Kawałek ma być nie tylko mały, ale samowystarczalny — żeby człowiek przeszedł go do końca i dostał obiecaną korzyść.

Robię to jednym chwytem: opisuję jeden główny scenariusz jednym akapitem, od pierwszej akcji użytkownika do momentu, w którym dostaje korzyść. Dla przykładu z kelnerem brzmi to tak: „Manager rano otwiera aplikację, zaznacza ptaszkami dania, których dziś nie ma, klika »Zapisz« — i każdy kelner ze swojego telefonu widzi aktualną listę stop-listy”.

Wszystko, co nie mieści się w tym jednym akapicie, na weekend nie istnieje. Rejestracja przez Google? Nie ma, jeden wspólny dostęp. Historia zmian? Nie ma. Analityka? Nie ma. Ustawienia profilu? Nie ma. Każde „a fajnie byłoby jeszcze” to godzina, której nie masz. Dyscyplina cięcia jest tu ważniejsza od jakiejkolwiek technologii.

Mały test zdolności kawałka do życia: wyobraź sobie, że pokazujesz wynik tej samej Marii, a ona mówi „o, tego używałabym już jutro”. Jeśli twój kawałek takiej reakcji nie wywołuje — jest za mały albo nie o to chodzi. Tnij dalej, ale w dobrym miejscu.

Krok 3: naszkicuj ekrany i przepływ (sobota, dzień)

Zanim otworzę jakiekolwiek narzędzie, rysuję. Dosłownie — na papierze albo w notatkach — sekwencję ekranów tego jednego scenariusza. Zwykle wychodzą dwa–trzy: ekran wprowadzania danych, ekran wyniku, czasem ekran potwierdzenia. Jeśli ekranów jest więcej niż pięć — wracam do kroku 2, bo czegoś nie dociąłem.

Ten szkic i jest moim zadaniem technicznym dla AI. Im konkretniej opiszę ekrany i przejścia między nimi, tym mniej iteracji zmarnuję. „Zrób aplikację dla restauracji” daje papkę. „Ekran z listą dań, przy każdym przełącznik »jest / nie ma«, przycisk »Zapisz« na dole; po zapisaniu — ekran z tymi daniami, które oznaczono jako »nie ma«, dużą czcionką” — daje to, co sobie wyobrażałem.

Intencja to nowy kod źródłowy. Poświęcam dwadzieścia minut na jasny opis przepływu właśnie dlatego, że te dwadzieścia minut oszczędza potem godzinę przeróbek.

Krok 4: złóż z AI w iteracjach (sobota, dzień — wieczór)

Dopiero teraz otwieramy narzędzie. W 2026 stos vibecodingu podzielił się na cztery ścieżki, a wybór zależy od ciebie, nie od mody:

• AI-edytory (Cursor, Windsurf) — dla tych, którym wygodnie widzieć i dotykać kodu.
• Agenci w terminalu (Claude Code) — do dłuższych, wieloplikowych zadań, gdy model sam chodzi po projekcie.
• Builderzy w przeglądarce (Lovable, Bolt, Replit, v0) — „z promptu do zdeployowanej aplikacji”, najniższy próg wejścia dla nietechnicznego foundera.

Popularne w 2026 podejście to hybryda: prototypujesz w builderze w przeglądarce, a gdy produkt zaczyna mieć znaczenie, przechodzisz do edytora kodu. Na weekend radzę zacząć tam, gdzie masz najmniej tarcia. Nietechnicznemu founderowi — builder w przeglądarce, bo daje działający ekran w kilka minut. Jeden ważny szczegół: builderzy w rodzaju Lovable i Bolt eksportują przenośny kod, który da się zdeployować gdziekolwiek, podczas gdy platformy z wszystkim „pod klucz” przywiązują bazę, autoryzację i hosting do siebie — a późniejsza migracja oznacza przepisanie infrastruktury od zera. Jeśli jest szansa, że projekt przeżyje, wybieram narzędzie, z którego da się zabrać kod.

Sam proces składania to cykl, a nie jeden wielki prompt:

1. Daj AI cały scenariusz i opis ekranów jedną wiadomością.
2. Zobacz, co wyszło, w aplikacji, nie w kodzie.
3. Nazwij jeden konkretny problem („przycisk nie zapisuje”, „lista pusta po odświeżeniu”) i odeślij go z powrotem.
4. Powtórz.

Drobny chwyt, który oszczędza najwięcej czasu: proś o jedną zmianę naraz. Duża wiadomość z dziesięcioma poprawkami daje dziesięć nowych miejsc, gdzie coś mogło się zepsuć, i nie wiesz, które. Małe kroki są szybsze, nawet jeśli wydają się wolniejsze.

Krok 5: dane i jedna–dwie integracje (sobota, wieczór)

Dwaj najwięksi pożeracze czasu na weekendzie to dane i integracje. Trzeba do nich podejść z tą samą zachłannością cięcia.

Dane. Bierz najprostszy magazyn, który działa. Na weekend cel jest taki, żeby dane nie znikały między sesjami, a nie żeby architektura przeżyła milion użytkowników. Większość builderów w przeglądarce daje wbudowaną bazę jednym kliknięciem — to wystarczy. Złożone modele danych, relacje między dziesięcioma encjami, optymalizacja zapytań — to nie jest zadanie na sobotni wieczór.

Integracje. Tu zasada jest twarda: jedna, najwyżej dwie. Każda zewnętrzna integracja to osobny świat kluczy autoryzacji, formatów, błędów i przypadków brzegowych. Wybieram tę jedną integrację, bez której produkt nie ma sensu — wysłać wiadomość na Telegram, przyjąć jedną płatność, zapisać wiersz w tabeli — i robię tylko ją. Resztę, jeśli bez niej naprawdę się nie da, imituję ręcznie: zamiast automatycznej wysyłki — przycisk, który pokazuje tekst do skopiowania samemu. Zaślepka, którą widzi żywy człowiek, na teście działa nie gorzej niż prawdziwa integracja, a kosztuje dziesięć razy mniej czasu.

Jeśli integracja zaczyna stawiać opór przez dwie godziny — to sygnał, żeby się zatrzymać i zapytać siebie, czy w ogóle jest potrzebna do testu. Najczęściej — nie.

Krok 6: test na prawdziwym użytkowniku (niedziela)

Niedziela nie jest o kodzie. Niedziela jest o tym, żeby posadzić przed aplikacją żywego człowieka, który nie jest tobą. To najważniejszy i najczęściej pomijany krok. Własnoręcznie złożony produkt zawsze działa w rękach autora — podświadomie omijasz jego słabe miejsca. Sens ma wyłącznie cudzy palec na cudzym ekranie.

Daję człowiekowi jedno zadanie — przejść główny scenariusz — i milczę. Nie podpowiadam, nie tłumaczę, nie usprawiedliwiam się. Po prostu patrzę, gdzie się zatrzymuje, co klika nie tam, gdzie mówi „a co teraz?”. Każde takie zawahanie to bug projektu, nawet jeśli kod jest idealny.

I właśnie tu rodzi się odpowiedź na pytanie, które męczy wszystkich: kiedy MVP jest wystarczająco dobre? Moje kryterium jest proste — wtedy, gdy obca osoba przechodzi główny scenariusz od początku do końca i dostaje obiecaną korzyść bez moich podpowiedzi z boku. Nie „gdy ładnie”, nie „gdy nie ma ani jednego buga”, tylko „gdy robi swoją jedną rzecz w cudzych rękach”. Cała reszta to kolejne iteracje, nie weekend.

Jeśli człowiek utknął — wracam do narzędzia i poprawiam dokładnie to miejsce, w którym utknął. Jedno przejście testu daje zwykle trzy–cztery drobne poprawki, każda na dziesięć minut. I to jest cała niedziela.

Krok 7: co dalej — i gdzie uczciwa granica

Pod koniec weekendu masz działającą rzecz, która rozwiązuje jeden ból jednego człowieka. To zwycięstwo. Ale tu włącza się najważniejsza uczciwość, bez której cała ta metodologia zmienia się w samooszukiwanie.

Zvibecodowane przez weekend MVP to prototyp i narzędzie wewnętrzne, a nie produkt produkcyjny. Granicę już w 2025 dokładnie wyznaczył Simon Willison: jeśli nie przeczytałeś i nie sprawdziłeś wygenerowanego kodu, nie wolno na nim polegać na produkcji. Między „zvibecodowałem przez weekend” a „to niezawodnie trzyma cudze dane i pieniądze” leży osobna, nieromantyczna praca: przeczytać kod, przetestować przypadki brzegowe, pozamykać podatności, ustawić obsługę błędów. Ja zawsze robię ten krok świadomie — a nie udaję, że go nie ma.

Dlatego „co dalej” zależy od wyniku testu:

• Człowiek się nie zaczepił — świetnie, w dwa dni i za grosze dowiedziałeś się, że pomysł jest nietrafiony. To najtańsza porażka w twoim życiu. Wyrzucaj bez żalu.
• Człowiek się zaczepił — teraz ma sens zainwestować w przekucie prototypu w niezawodny produkt: przeczytać kod, dołożyć jeszcze kilku ludzi, stopniowo pozamykać to, co świadomie wyciąłeś na weekend.

Siła tego procesu nie polega na tym, że w weekend robisz biznes. Polega na tym, że w weekend i za marne pieniądze dostajesz odpowiedź — czy warto budować dalej. Większość pomysłów tej próby nie przechodzi, i to najlepsze, co może je spotkać.

Checklista weekendu

Żeby nie trzymać wszystkiego w głowie, oto mój zwinięty plan na dwa dni.

To nie magia i nie bohaterstwo. To dyscyplina cięcia pomnożona przez szybkość, którą AI w końcu dało founderowi bez zespołu programistów. Najtrudniejszy pozostaje nie kod — kod jest teraz tani. Najtrudniejsza jest uczciwość, żeby zawęzić wielki pomysł do jednego małego, który da się realnie sprawdzić w dwa dni. Kto opanuje to zawężanie, ten za każdy weekend będzie dostawał odpowiedź, na którą wcześniej szły miesiące i budżety.