MVP bez wspólnika technicznego: przewodnik foundera od pomysłu do pierwszych użytkowników

W startupowym poradniku pierwszy krok brzmi niemal zawsze tak samo: najpierw znajdź wspólnika-programistę. Bez własnego CTO pomysł ma podobno stać w miejscu, a nietechniczny founder czekać, aż ktoś „ogarnie techniczną stronę”. W praktyce to przekonanie zatrzymuje więcej projektów niż brak pieniędzy: miesiące na szukanie technicznego wspólnika, a potem oddane 30–50% udziałów, zanim powstanie choćby jeden klikalny ekran.

Jest druga droga, o której poradniki milczą, bo nie mieści się w micie o garażu i dwóch założycielach. Nie musisz oddawać połowy firmy, żeby dojść do pierwszych użytkowników. Możesz kupić godziny pracy inżyniera – tak jak kupujesz pracę księgowej czy prawnika – i zachować pomysł, kierunek oraz kod w całości u siebie. Zamiast szukać programisty do startupu na etat, wynajmujesz software house dla startupu na tyle godzin, ile realnie potrzebujesz.

Ten wpis to przewodnik krok po kroku dla foundera, który nie zna się na technologii i nie ma technicznego wspólnika: od pomysłu opisanego jednym zdaniem do pierwszych zalogowanych użytkowników. Z liczbami wprost i uczciwym akapitem o tym, kiedy lepiej poczekać.

Wspólnik techniczny czy kupione godziny? Co naprawdę oddajesz udziałami

Techniczny wspólnik bywa świetnym rozwiązaniem – ma sens, gdy produkt jest z gruntu technologiczny, a horyzont liczy się w latach. Ale dla nietechnicznego foundera na etapie walidacji to często najdroższy sposób napisania pierwszej wersji. Zanim porównasz, warto zobaczyć, co dokładnie kryje się w każdej z opcji.

• Wspólnik-programista – stała dostępność, ale kosztem 30–50% udziałów oddanych na zawsze, ryzyka konfliktu o kierunek i scenariusza, w którym rozejście się założycieli zostawia projekt bez rąk do kodu.
• Programista na etat – sensowny, gdy pracy jest na lata; przy walidacji pomysłu to 25–35 tys. zł miesięcznie za kogoś, kto po pierwszej wersji może nie mieć co robić.
• Kupione godziny (my) – 600 zł netto za godzinę, płacisz za realnie przepracowany czas, bez udziałów i bez etatu, a kod oraz prawa majątkowe są w 100% Twoje po każdym etapie.

Różnica sprowadza się do jednego pytania: czy na tym etapie potrzebujesz człowieka na pokładzie na stałe, czy raczej pierwszych użytkowników i danych? Nietechniczny founder przed walidacją prawie zawsze potrzebuje tego drugiego, a to można kupić na godziny, bez naruszania struktury właścicielskiej.

Krok 1: opisz pomysł bez specyfikacji

Najczęstszy powód, dla którego pomysł latami leży w szufladzie, nie jest finansowy. To przekonanie, że najpierw trzeba napisać specyfikację, a nietechniczny founder nie wie, jak się do tego zabrać. Dobra wiadomość: nie musisz. Projekt zaczyna się od 30 minut zwykłej rozmowy, nie od dokumentu.

Mam pomysł na aplikację, w której trenerzy personalni układają plany dla podopiecznych, a ci odhaczają je z telefonu. Nie znam się na technologii i nie mam wspólnika-programisty. Od czego zacząć?

Na tej rozmowie opowiadasz o problemie i użytkownikach jak znajomemu, a inżynier zamienia to na zakres i szacunek godzin na piśmie. Wszystko, co powiesz i wyślesz, obejmuje NDA – automatycznie, z regulaminu, od pierwszej wiadomości, bez podpisywania czegokolwiek na wszelki wypadek.

• Jedno zdanie o problemie – „chcę, żeby klienci sami rezerwowali terminy i dostawali przypomnienie” to działający punkt startu.
• Cokolwiek wizualnego – schemat na serwetce, zdjęcie tablicy, link do aplikacji, która w innej branży działa podobnie.
• Kto jest użytkownikiem – komu i w jakim momencie ma to ułatwić życie. To ważniejsze niż jakakolwiek lista funkcji.

Krok 2: makieta czy od razu MVP? Uczciwa odpowiedź

To pytanie rozstrzyga, ile wydasz na starcie – i tu founderowi bez technicznego wspólnika najłatwiej przepłacić, bo nie ma obok kogoś, kto powie „poczekaj, na razie wystarczy mniej”. Dlatego mówimy to my, mimo że sprzedajemy godziny.

• Masz hipotezę, czy ludzie tego w ogóle chcą? → makieta. Klikalny prototyp jednej głównej funkcji: realne ekrany, realny przepływ, dane testowe, bez bazy danych. 10 godzin: 6 000 zł netto, typowo tydzień. Wystarcza, by pokazać pomysł dziesięciu osobom z grupy docelowej i zmierzyć reakcje, zamiast zgadywać.
• Masz hipotezę, czy będą wracać i zostawią dane? → MVP. Rejestracja, baza, wdrożenie na serwer, prawdziwi użytkownicy. 30 godzin: 18 000 zł netto.
• Masz potwierdzony popyt i chcesz pobierać pieniądze? → produkt, z płatnościami i panelem. 60 godzin: 36 000 zł netto.

A kiedy warto poczekać? Gdy pomysłu nie sprawdziłeś jeszcze na żadnym prawdziwym rozmówcy. Jeśli nie wiesz, kto i po co miałby tego używać, nie zaczynaj od MVP – zacznij od makiety i dziesięciu szczerych rozmów. Czasem ich wynik brzmi „odpuszczam” i to też jest świetny wynik: negatywna walidacja za 6 000 zł to jedna z najtańszych lekcji na rynku, dużo tańsza niż rok budowania produktu, którego nikt nie chciał. Poczekaj również, jeśli budżet masz dokładnie na budowę i ani złotówki dalej, bo aplikacja żyje: hosting, drobne poprawki, rozwój.

Krok 3: jak kontrolować budżet i zakres bez wiedzy technicznej

Największy lęk nietechnicznego foundera brzmi: „nie znam się, więc będą mi dowozić godziny w nieskończoność, a ja się nie połapię”. To uczciwy lęk, bo rozliczenie godzinowe bez kontroli potrafi być taksometrem bez licznika. Dlatego licznik jest u nas największą częścią współpracy i należy do Ciebie, nawet jeśli nie odróżniasz bazy danych od serwera.

• Estymata przed pracą. Każdy etap dostaje z góry szacunek godzin. Akceptujesz, dopiero potem ktokolwiek zaczyna. Żadna praca nie rusza „bo tak wyszło”.
• Live log godzin w panelu. Każdy wpis to konkret po ludzku: „2,5 h – ekrany logowania, wdrożenie na wersję testową”. Widzisz, na co poszła każda godzina, zanim zejdzie z salda – jak wyciąg z konta, nie faktura-niespodzianka na koniec miesiąca.
• Akceptacje etapów. Nie idziemy dalej bez Twojego „ok”. Zakres rośnie tylko wtedy, gdy Ty go rozszerzasz.
• Stop w każdej chwili. Przerywasz bez kar i tłumaczenia; płacisz za zrobione, a niewykorzystane godziny zostają na saldzie.

Zostaje pytanie, które zadaje każdy founder: dlaczego u nas MVP to 30 godzin, a gdzie indziej trzy miesiące? Nie dlatego, że ktoś szybciej pisze na klawiaturze. Robi to akcelerator: własne, sprawdzone w setkach wdrożeń SDK aveneo (gotowe logowanie, płatności, panele), AI jako drugie ręce przy powtarzalnym kodzie oraz automatyczne wdrożenia. W efekcie jedna godzina ma przebieg mniej więcej trzech do pięciu godzin klasycznej pracy, czyli budujesz 3–5× szybciej niż solowy programista od zera. Senior nie odtwarza schematów z pamięci, tylko podejmuje decyzje.

Nie musisz umieć czytać kodu, żeby panować nad projektem. Musisz umieć czytać log i saldo – a to wygląda jak historia transakcji w bankowości mobilnej. Gdy coś jest niejasne, pytasz na czacie tego samego inżyniera, który to zbudował.

Krok 4: pierwsi użytkownicy

MVP nie jest celem samym w sobie – jest narzędziem do zdobycia pierwszych użytkowników i pierwszych liczb. Po wdrożeniu na serwer dostajesz link do działającej aplikacji dla startupu: ludzie się logują, zostawiają dane i wracają albo nie wracają, a Ty pierwszy raz patrzysz na zachowania zamiast na opinie znajomych.

Jak dojść do tych pierwszych użytkowników bez działu marketingu i bez obietnic, że „samo się rozejdzie”? Wąsko i konkretnie:

• Jedna grupa docelowa, nie „wszyscy”. Dziesięciu realnych użytkowników z jednej niszy powie Ci więcej niż tysiąc przypadkowych wejść.
• Jeden kanał na start. Grupa na branżowym forum, znajomi z rynku, do którego celujesz, kilka bezpośrednich rozmów. Nie potrzebujesz kampanii, żeby sprawdzić, czy rdzeń działa.
• MVP celowo robi jedną rzecz dobrze. Wszystko, co „byłoby miło mieć”, czeka, aż pierwsi użytkownicy potwierdzą, że rdzeń ma sens.

Gdy liczby zaczną bronić kolejnego kroku, MVP rozwija się w produkt (60 h · 36 000 zł netto): płatności, panel administracyjny, integracje. Kod jest kontynuowany, nie wyrzucany, bo od pierwszej godziny powstaje na produkcyjnych standardach, nie „na szybko do pokazania”.

← wszystkie wpisy