Founderka ma prototyp w Figmie, list intencyjny od pierwszego klienta i 600 tysięcy złotych z rundy pre-seed. Rozmawia z czterema software house’ami. Trzy pokazują podobne portfolio: aplikacje dla fintechów, marketplace’y, panele SaaS z ładnymi zrzutami ekranu. Czwarty ma skromniejsze referencje, ale na pierwszym spotkaniu przesyła wzór umowy i pyta, na czyim koncie GitHub ma powstać repozytorium. Founderka wybiera jednego z trzech pierwszych, bo jego case studies najbardziej przypominają jej produkt.
Osiem miesięcy później produkt działa, pierwsi użytkownicy płacą, a fundusz zainteresowany rundą seed wysyła listę pytań do due diligence. Jedno z nich brzmi: „Proszę przedstawić umowy potwierdzające nabycie przez spółkę autorskich praw majątkowych do kodu źródłowego”. Okazuje się, że umowa z wykonawcą mówi o „przekazaniu kodu po zakończeniu projektu i uregulowaniu wszystkich należności”, a projekt formalnie się nie zakończył. Repozytorium jest w organizacji wykonawcy. Konto w chmurze też. Rozmowa o rundzie zatrzymuje się na kilka tygodni, a wykonawca dobrze wie, że w tej chwili ma przewagę negocjacyjną.
Ten artykuł jest dla founderów i prezesów startupów, którzy wybierają zewnętrznego partnera do budowy MVP. Teza może brzmieć przekornie: najlepszym predyktorem dobrej współpracy z wykonawcą MVP nie jest jego portfolio, tylko to, jak łatwo będzie od niego odejść. Partner, który od pierwszego dnia trzyma kod, konta i prawa po Twojej stronie, nie musi Cię trzymać umową. Musi Cię trzymać jakością pracy. Właśnie takiego szukasz.
Dlaczego portfolio software house’u mówi mniej, niż myślisz?
Portfolio pokazuje, co firma zbudowała, ale nie pokazuje trzech rzeczy, które dla startupu są najważniejsze: kto konkretnie to budował, ile to trwało w stosunku do planu i jak zakończyła się współpraca. Zrzuty ekranu z aplikacji fintechowej nie mówią, czy ludzie, którzy ją pisali, nadal pracują w tej firmie i czy trafią do Twojego projektu. Nie mówią też, czy klient po roku przeniósł rozwój do własnego zespołu bez problemu, czy przez trzy miesiące odtwarzał dokumentację.
Drugi problem: portfolio jest wyselekcjonowane. Nikt nie pokazuje projektów, które przekroczyły budżet dwukrotnie albo zakończyły się sporem. To naturalne i nie świadczy o nieuczciwości, ale oznacza, że próbka jest z definicji zawyżona. Porównując trzy portfolio, porównujesz trzy najlepsze kawałki, a nie średnią, którą dostaniesz.
Trzeci problem jest specyficzny dla MVP. Minimum viable product ma sprawdzić hipotezę, a nie zachwycić wyglądem. Wykonawca, który świetnie robi dopracowane aplikacje dla korporacji, nie musi umieć szybko wypuszczać wersji, z której połowa zostanie wyrzucona po pierwszych rozmowach z użytkownikami. Dla startupu ważniejsze jest tempo uczenia się niż elegancja pierwszej wersji, o czym szerzej pisaliśmy w przewodniku od pomysłu do product-market fit.
Co zatem mówi więcej niż portfolio? Wzór umowy, który wykonawca przesyła bez proszenia. Odpowiedź na pytanie, gdzie będzie repozytorium. Gotowość do krótkiego, płatnego etapu próbnego. I to, jak firma opowiada o klientach, którzy od niej odeszli. Te sygnały kosztują wykonawcę więcej niż ładne zrzuty ekranu, dlatego są bardziej wiarygodne.
Jakiego partnera właściwie potrzebuje startup na etapie MVP?
Zanim zaczniesz porównywać firmy, zdecyduj, jakiego rodzaju współpracy potrzebujesz. „Software house” to szerokie pojęcie, a dla MVP realnie wchodzą w grę cztery modele. Każdy przenosi na foundera inną część odpowiedzialności.
Freelancer lub mały zespół freelancerów. Najtańszy na start i najszybszy w uruchomieniu. Ryzyko: jedna osoba choruje albo dostaje lepszą ofertę i projekt staje. Prawa do kodu trzeba zabezpieczać osobno z każdą osobą. Sprawdza się, gdy w zespole założycielskim jest osoba techniczna, która potrafi ocenić kod i przejąć go w razie potrzeby.
Software house realizujący projekt. Wykonawca bierze odpowiedzialność za dostarczenie produktu: projekt interfejsu, programowanie, testy, wdrożenie. Founder kupuje wynik, a nie godziny. Ryzyko: im bardziej wykonawca „prowadzi” projekt, tym mniej wiedzy zostaje w startupie, a im mniej wiedzy, tym droższe odejście.
Zespół dedykowany. Wykonawca dostarcza stały zespół, który pracuje tylko nad Twoim produktem, a priorytety ustala founder lub product owner po stronie startupu. To model pośredni: ciągłość jak we własnym zespole, bez rekrutacji. Wymaga, żeby ktoś w startupie realnie zarządzał backlogiem.
Uzupełnienie zespołu (staff augmentation). Wykonawca dostarcza pojedynczych specjalistów do zespołu, którym kieruje startup. Ma sens, gdy jest już techniczny współzałożyciel lub CTO, a brakuje rąk do pracy albo konkretnej kompetencji, na przykład programisty mobilnego.
Wybór modelu zależy głównie od jednego pytania: czy w zespole założycielskim jest ktoś, kto potrafi ocenić jakość kodu i architektury? Jeśli tak, możesz kupować godziny i samodzielnie kierować pracą. Jeśli nie, kupujesz również osąd techniczny, a wtedy umowa musi szczególnie mocno chronić Twój dostęp do kodu i wiedzy, bo sam nie wychwycisz problemów na czas.
| Model | Kto kieruje pracą | Ryzyko dla foundera | Kiedy ma sens |
|---|---|---|---|
| Freelancer | Founder | Zależność od jednej osoby, rozproszone prawa | Jest techniczny współzałożyciel |
| Software house (projekt) | Wykonawca | Wiedza zostaje u wykonawcy | Brak kompetencji technicznych, jasno opisany pierwszy etap |
| Zespół dedykowany | Founder lub PO startupu | Wymaga aktywnego zarządzania | Produkt będzie rozwijany ponad 6 miesięcy |
| Staff augmentation | CTO startupu | Brak odpowiedzialności za wynik po stronie wykonawcy | Jest CTO, brakuje ludzi lub specjalizacji |
Jak sprawdzić wykonawcę, zanim podpiszesz umowę na całe MVP?
Najlepsza weryfikacja to krótki, płatny etap, po którym możesz odejść bez straty. Zamiast podpisywać umowę na całe MVP po trzech spotkaniach handlowych, zamów najpierw discovery: doprecyzowanie zakresu, architekturę, plan pierwszych sprintów i wycenę. U nas taka faza trwa 1–2 tygodnie i służy do ustalenia zakresu i architektury. O tym, co powinna dać, pisaliśmy w artykule o warsztatach odkrywczych.
Discovery jest testem w obie strony. Zobaczysz, jak wykonawca zadaje pytania, czy podważa założenia, czy tylko je notuje, i czy dokumenty, które powstaną, będą zrozumiałe dla kogoś spoza jego zespołu. Ważne: umowa na discovery musi przenosić na Ciebie prawa do wyników, żebyś mógł użyć ich w rozmowie z innym wykonawcą, jeśli zdecydujesz się nie kontynuować. Wykonawca, który się na to nie zgadza, właśnie powiedział Ci coś istotnego.
Druga zasada: rozmawiaj z ludźmi, którzy będą pisać kod. Na spotkaniach handlowych pojawiają się najczęściej doświadczeni architekci i dyrektorzy, a do projektu trafia potem inny skład. Poproś o nazwiska osób planowanych do zespołu i o godzinną rozmowę techniczną z co najmniej jedną z nich. Zapisz w umowie, że skład kluczowych osób nie zmieni się bez Twojej zgody, a jeśli zmiana będzie konieczna, wykonawca zapewni zastępstwo w określonym terminie.
Trzecia zasada: poproś o kontakt do klienta, który od wykonawcy odszedł. Referencje od zadowolonych, aktywnych klientów są łatwe do zdobycia. Klient, który przeniósł rozwój do własnego zespołu albo do innej firmy, powie Ci, jak wyglądało przekazanie kodu, czy dokumentacja istniała i czy wykonawca współpracował do końca. Jeśli wykonawca nie potrafi wskazać żadnego takiego klienta, zapytaj dlaczego.
Czwarta zasada: przeczytaj wzór umowy przed rozmową o cenie. Cena jest łatwa do porównania i dlatego zdominuje negocjacje, jeśli pozwolisz jej wejść pierwsza. Tymczasem różnica 15% w stawce jest mniej ważna niż różnica między „prawa przechodzą z chwilą zapłaty każdej faktury” a „prawa przechodzą po odbiorze końcowym”. Szerszą listę pytań do wykonawcy znajdziesz w naszym przewodniku jak wybrać firmę programistyczną, tu skupiamy się na tym, co jest specyficzne dla startupu i MVP.
Fixed price czy time and materials: który model rozliczenia chroni foundera?
Intuicja podpowiada stałą cenę. Startup ma ograniczony budżet, inwestor pyta, ile będzie kosztować MVP, a stała cena wygląda jak gwarancja. W praktyce w MVP stała cena chroni foundera słabiej, niż się wydaje, i to jest drugie stanowisko tego artykułu, z którym wielu doradców się nie zgodzi.
Powód jest prosty. Stała cena wymaga stałego zakresu. A zakres MVP ma się zmieniać, bo celem MVP jest uczenie się na reakcjach użytkowników. Jeśli po pierwszych pięciu rozmowach z klientami okaże się, że funkcja raportów jest niepotrzebna, a kluczowy jest import danych z arkusza, w modelu stałej ceny otwierasz procedurę zmiany zakresu: wycena, negocjacje, aneks. Każda zmiana kosztuje czas i daje wykonawcy okazję do odrobienia strat z innych pozycji.
Do tego wykonawca, który bierze na siebie ryzyko stałej ceny przy niepewnym zakresie, dolicza premię za to ryzyko. Nie jest to zarzut, tylko racjonalne zachowanie. Płacisz więc za ochronę przed ryzykiem, którego część i tak wróci do Ciebie w postaci sporów o zakres. W efekcie oba modele mogą kosztować podobnie, ale stała cena kosztuje dodatkowo elastyczność, czyli to, czego MVP potrzebuje najbardziej.
Co w zamian? Time and materials z mechanizmami kontroli, które dają przewidywalność bez sztywności:
- miesięczny limit budżetu, którego wykonawca nie może przekroczyć bez Twojej pisemnej zgody;
- krótkie sprinty (u nas standardem są dwutygodniowe), po każdym działająca wersja do obejrzenia;
- cotygodniowy raport z godzinami w podziale na zadania i osoby;
- prawo do zakończenia współpracy z krótkim wypowiedzeniem, bez kar umownych;
- budżet na zakres zamiast listy funkcji: ustalasz, ile chcesz wydać na pierwszą wersję, a priorytety zmieniasz w ramach tej kwoty.
Stała cena ma swoje miejsce: dla zamkniętego, dobrze opisanego etapu, takiego jak discovery, audyt istniejącego kodu albo konkretna integracja ze znanym API. Tam zakres jest stabilny i stała cena naprawdę chroni obie strony. Rząd wielkości budżetu na całe MVP możesz oszacować w naszym kalkulatorze kosztów MVP; w tym artykule nie wchodzimy w koszty, tylko w to, jak je kontrolować w umowie.
Czy warto płacić wykonawcy udziałami w spółce?
Na etapie pre-seed oferta „zbudujemy Ci MVP w zamian za 10–20% udziałów” brzmi kusząco. Founder oszczędza gotówkę, a wykonawca staje się zainteresowany sukcesem produktu. W praktyce taki układ najczęściej szkodzi obu stronom i warto go traktować jako rozwiązanie ostateczne.
Pierwszy problem to konflikt ról. Wykonawca z udziałami jest jednocześnie dostawcą i wspólnikiem. Jako dostawca powinien przekazywać Ci wiedzę i ułatwiać budowę własnego zespołu. Jako wspólnik, który nie dostaje wynagrodzenia w gotówce, ma interes w tym, żeby pozostać niezbędnym, bo tylko wtedy jego udział ma wpływ na decyzje. To nie musi być świadoma strategia; wystarczy, że jest naturalnym kierunkiem.
Drugi problem to kolejna runda. Inwestor zobaczy w tabeli udziałów podmiot, który posiada istotny pakiet, nie pracuje w spółce na pełen etat i nie wniósł gotówki. Część funduszy uzna to za sygnał ostrzegawczy, a w najlepszym razie zapyta, co się stanie, jeśli wykonawca przestanie pracować nad produktem. Na to pytanie trudno odpowiedzieć, jeśli udziały zostały wydane z góry.
Trzeci problem jest prawny i dotyczy kodu. Umowa o udziały za pracę bywa pisana z myślą o udziałach, a prawa autorskie traktuje się w niej jako oczywistość. Nie są oczywistością. Jeśli wykonawca jest wspólnikiem, a umowa nie przenosi praw do kodu na spółkę w sposób wymagany przez prawo, kod może formalnie należeć do wykonawcy albo do jego programistów.
Jeśli mimo to udziały za kod są jedynym sposobem na start, zabezpiecz się trzema zapisami: udział jest ograniczony i nabywany stopniowo w miarę dostarczania kamieni milowych (vesting), spółka ma prawo odkupu nienabytych jeszcze udziałów przy zakończeniu współpracy, a prawa do kodu przechodzą na spółkę na tych samych zasadach, jak gdyby wykonawca dostawał wynagrodzenie w gotówce. Połączenie gotówki z niewielkim udziałem jest zwykle zdrowsze niż sam udział.
Kto jest właścicielem kodu MVP i jak to zapisać w umowie?
To najważniejsza sekcja artykułu i ta, którą founderzy najczęściej odkładają na później. Bez prawidłowo przeniesionych praw do kodu Twoja spółka nie jest właścicielem swojego głównego aktywa, a każdy inwestor i nabywca to sprawdzi.
W Polsce podstawą jest ustawa o prawie autorskim i prawach pokrewnych (tekst jednolity Dz.U. 2025 poz. 24). Program komputerowy jest w niej chroniony jak utwór. Z perspektywy startupu zamawiającego kod liczą się cztery przepisy.
Forma pisemna. Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53). Mail z akceptacją oferty, zamówienie w systemie czy „akceptuję regulamin” nie wystarczą. Potrzebny jest dokument podpisany własnoręcznie lub kwalifikowanym podpisem elektronicznym. Projekt nowelizacji, który miał złagodzić ten wymóg, nie wszedł w życie.
Pola eksploatacji. Umowa obejmuje tylko pola eksploatacji wyraźnie w niej wymienione (art. 41 ust. 2) i tylko pola znane w chwili jej zawarcia (art. 41 ust. 4). Dla programu komputerowego obejmuje to w szczególności trwałe lub czasowe zwielokrotnianie, tłumaczenie, przystosowywanie i zmiany układu oraz rozpowszechnianie. Zapis „przenosi wszystkie prawa do kodu” bez wyliczenia pól to proszenie się o spór. Dobra umowa wymienia pola wprost i dodaje zgodę na wykonywanie praw zależnych, czyli na modyfikację kodu przez Ciebie lub innego wykonawcę.
Przyszłe utwory. Umowa jest nieważna w zakresie dotyczącym wszystkich utworów albo wszystkich utworów określonego rodzaju tego samego twórcy, które mają powstać w przyszłości (art. 41 ust. 3). W praktyce umowy ramowe radzą sobie z tym, wiążąc przeniesienie praw z konkretnymi, zidentyfikowanymi wynikami pracy, na przykład z kodem dostarczonym w danym sprincie i opisanym w protokole lub fakturze. To nie jest formalność, tylko mechanizm, który decyduje, czy przeniesienie jest skuteczne.
Pracownicy a kontraktorzy. Prawa majątkowe do programu stworzonego przez pracownika w ramach obowiązków ze stosunku pracy przysługują pracodawcy, o ile umowa nie stanowi inaczej (art. 74 ust. 3). Ten przepis dotyczy jednak tylko umowy o pracę. W polskiej branży IT duża część programistów pracuje na kontraktach B2B. Jeśli kod Twojego MVP pisze osoba na B2B, prawa najpierw powstają u niej, a nie u software house’u. Wykonawca może Ci przenieść tylko to, co sam skutecznie nabył.
Z tego wynika łańcuch, który musi być ciągły: programista → wykonawca → Twoja spółka. W umowie poproś o oświadczenie, że wykonawca nabył lub nabędzie od wszystkich osób pracujących nad projektem prawa w zakresie co najmniej takim, jaki przenosi na Ciebie, i o prawo wglądu w te umowy przy due diligence. Szczegóły prawne własności kodu omówiliśmy w osobnym artykule o własności intelektualnej w IT.
Moment przejścia praw. To zapis, który decyduje o Twojej pozycji negocjacyjnej w razie sporu. Wariant zły: „prawa przechodzą po odbiorze końcowym i zapłacie całości wynagrodzenia”. Jeśli projekt się nie zakończy albo pojawi się spór o jedną fakturę, nie masz praw do niczego. Wariant dobry: „prawa do kodu dostarczonego w danym okresie rozliczeniowym przechodzą z chwilą zapłaty faktury za ten okres”. Wtedy spór o ostatni miesiąc dotyczy ostatniego miesiąca, a nie całego produktu.
Co z bibliotekami open source i komponentami, które wykonawca przynosi ze sobą?
Żadne współczesne MVP nie powstaje od zera. Składa się z frameworków, bibliotek open source, gotowych usług chmurowych i często z wewnętrznych komponentów wykonawcy: modułu logowania, szablonu panelu administracyjnego, narzędzi do wdrożeń. Każda z tych warstw ma innego właściciela i inną licencję, a umowa musi to rozróżniać.
Komponenty wykonawcy (background IP). Software house nie przeniesie na Ciebie praw do modułu, którego używa u dziesięciu klientów, i nie powinieneś tego oczekiwać. Powinieneś natomiast oczekiwać licencji na te komponenty, która jest niewyłączna, bezterminowa, nieodwołalna, nieodpłatna (bo zapłaciłeś już za projekt), obejmująca prawo do modyfikacji i przenoszalna na nabywcę Twojej spółki lub na innego wykonawcę. Bez takiej licencji po rozstaniu masz kod, którego nie możesz legalnie uruchomić.
Licencje open source. Większość popularnych licencji (MIT, Apache 2.0, BSD) pozwala na swobodne użycie w produkcie komercyjnym przy zachowaniu informacji o autorach. Inaczej jest z licencjami typu copyleft. Licencja GNU AGPL w wersji 3 w sekcji 13 wymaga udostępnienia kodu źródłowego zmodyfikowanej wersji użytkownikom, którzy korzystają z programu przez sieć. Dla startupu SaaS może to oznaczać obowiązek udostępnienia części własnego kodu. Nie każde użycie biblioteki AGPL rodzi taki skutek, ale decyzja o jej użyciu powinna być świadoma, a nie przypadkowa.
W umowie zapisz trzy rzeczy: wykonawca prowadzi listę wszystkich komponentów zewnętrznych z ich licencjami (w praktyce jest to SBOM, czyli software bill of materials, generowany automatycznie przez narzędzia w pipeline), nie wprowadza komponentów na licencjach copyleft bez Twojej pisemnej zgody, i przekazuje aktualną listę przy każdym wydaniu. To kilka minut pracy dla zespołu, który ma porządny proces CI/CD, i potężne ułatwienie przy due diligence.
Kod generowany przez narzędzia AI. Programiści coraz częściej korzystają z asystentów generujących kod. Status prawny takiego kodu nie jest w pełni wyjaśniony, a narzędzia mogą odtwarzać fragmenty kodu na licencjach, które nie pasują do Twojego produktu. Rozsądnym minimum jest zapis, że wykonawca używa takich narzędzi wyłącznie w konfiguracji, która nie przekazuje Twojego kodu do trenowania modeli, i że odpowiada za zgodność dostarczonego kodu z licencjami niezależnie od tego, jak powstał.
Gdzie powinny leżeć repozytorium, konta i klucze od pierwszego dnia?
Po Twojej stronie. To najprostszy i najskuteczniejszy zapis w całej umowie, a mimo to najczęściej pomijany, bo na początku projektu wydaje się techniczną drobnostką. Prawa autorskie na papierze niewiele dają, jeśli fizycznie nie masz dostępu do kodu.
Lista zasobów, które powinny być założone na spółkę i administrowane przez osobę ze startupu, z dostępem nadanym wykonawcy:
- repozytorium kodu (organizacja w GitHub, GitLab lub Bitbucket należąca do spółki);
- konto chmurowe (AWS, Azure, Google Cloud) z rozliczeniem na kartę lub fakturę spółki;
- domena i DNS;
- konta deweloperskie w sklepach z aplikacjami (Apple App Store, Google Play), które przy aplikacjach mobilnych są szczególnie trudne do przeniesienia później;
- narzędzia do zarządzania projektem (Jira, Linear, Notion) i dokumentacja;
- sekrety i klucze API w menedżerze sekretów pod kontrolą spółki;
- konta usług zewnętrznych: płatności, wysyłka e-maili, analityka, monitoring błędów.
Zasada jest jedna: wykonawca dostaje dostęp, a nie własność. Ty możesz ten dostęp odebrać jednym kliknięciem. Wykonawca nie może Ci go odebrać wcale. Gdy repozytorium jest u Ciebie od pierwszego commita, depozyt kodu źródłowego (escrow) przestaje być potrzebny, bo nie ma czego deponować: kod i jego historia są u Ciebie na bieżąco.
Dobry wykonawca przyjmuje taki układ bez dyskusji, bo dla niego nie zmienia niczego w codziennej pracy. Wykonawca, który przekonuje, że „lepiej, żeby repozytorium było u nas, bo mamy skonfigurowane pipeline’y”, proponuje Ci rozwiązanie wygodne dla siebie. Pipeline’y można skonfigurować w Twojej organizacji tak samo. Szerzej o mechanizmach uzależnienia od dostawcy pisaliśmy w artykule o vendor lock-in.
Jak zapisać wyjście z umowy, zanim będzie potrzebne?
Klauzulę wyjścia pisze się w dobrych czasach, bo w złych nikt już nie negocjuje rozsądnie. Startup może chcieć zakończyć współpracę z wielu powodów, z których większość nie jest winą wykonawcy: zmiana kierunku produktu, budowa własnego zespołu po rundzie, brak finansowania, przejęcie przez większą firmę. Umowa powinna zakładać, że rozstanie jest normalną częścią cyklu życia startupu.
Okres wypowiedzenia. Liczony w tygodniach, nie w kwartałach. Trzy miesiące wypowiedzenia przy miesięcznym budżecie rzędu kilkudziesięciu tysięcy złotych to istotna część rundy pre-seed wydana na pracę, której już nie potrzebujesz. U nas okres wypowiedzenia wynosi 30 dni, bez kar umownych, i płaci się tylko za faktycznie przepracowane dni. To dobry punkt odniesienia przy porównaniu ofert.
Obowiązek przekazania. Wykonawca w okresie wypowiedzenia przekazuje: kompletny kod z historią (jeśli repozytorium jest u Ciebie, to jest formalność), dokumentację architektury i wdrożenia, instrukcję uruchomienia środowiska lokalnego, listę dostępów do odebrania, listę znanych błędów i długu technicznego oraz określoną liczbę godzin na sesje przekazania wiedzy nowemu zespołowi. Te godziny są rozliczane według zwykłej stawki, ale nie mogą być odmówione.
Brak opłat za wyjście. Żadnych „opłat za przekazanie kodu”, „opłat licencyjnych po zakończeniu umowy” ani „wynagrodzenia za udzielenie praw zależnych”. Wynagrodzenie za prawa jest zawarte w wynagrodzeniu za pracę. Dobrze zapisać to wprost.
Niezależność od sporu. Prawa do opłaconych części kodu i obowiązek przekazania obowiązują niezależnie od sporu o pozostałe należności. Spór o ostatnią fakturę rozstrzyga się osobno, a nie przez wstrzymanie dostępu do produktu.
Zakaz zatrudniania. Wykonawcy często wpisują zakaz zatrudniania swoich specjalistów przez klienta. Zrozumiały interes, ale dla startupu, który po rundzie chce przejąć jedną lub dwie kluczowe osoby do własnego zespołu, sztywny zakaz jest problemem. Lepszy jest zapis z opłatą za przejęcie, ustaloną z góry, niż zakaz bez wyjątków.
Jeśli przejmujesz MVP od poprzedniego wykonawcy i nie wiesz, w jakim stanie jest kod, warto przed decyzją zlecić niezależny audyt kodu i due diligence techniczne. U nas taki audyt trwa 1–2 tygodnie, ma stały zakres i zaczyna się od 18 000 PLN; raport należy do Ciebie i możesz go użyć niezależnie od tego, kto będzie dalej rozwijał produkt.
Jakie gwarancje jakości i odbioru mają sens w MVP?
W MVP łatwo popaść w dwie skrajności. Pierwsza: brak jakichkolwiek kryteriów jakości, bo „to tylko MVP”. Druga: przeniesienie do umowy wymagań z projektów korporacyjnych, z pokryciem testami na poziomie 90% i wielotygodniowymi procedurami odbioru. Pierwsza kończy się kodem, którego nie da się rozwijać. Druga kończy się MVP, które nie wychodzi na rynek.
Rozsądny środek to definicja ukończenia (definition of done) zapisana w załączniku do umowy. Zadanie jest ukończone, gdy kod przeszedł przegląd przez drugą osobę, ma testy automatyczne dla logiki biznesowej, jest wdrożony na środowisko testowe przez pipeline, a nie ręcznie, i ma zaktualizowaną dokumentację, jeśli zmienia sposób uruchomienia lub konfiguracji. To nie jest wymóg luksusowy. To minimum, które pozwala innemu zespołowi przejąć kod.
Odbiór. W modelu time and materials nie ma klasycznego odbioru końcowego, ale warto zapisać przegląd po każdym sprincie z krótkim terminem na zgłoszenie zastrzeżeń. Zastrzeżenia niezgłoszone w terminie oznaczają akceptację. Brzmi to jak ustępstwo na rzecz wykonawcy, ale w praktyce chroni obie strony przed sporem o pracę sprzed czterech miesięcy.
Okres gwarancji. Zapis, że wykonawca bezpłatnie usuwa błędy w dostarczonym kodzie zgłoszone w określonym czasie od wydania, na przykład trzech miesięcy. Ważne rozróżnienie: błąd to niezgodność z ustaloną specyfikacją lub definicją ukończenia, a nie nowa funkcja, o której zapomniano. Bez tego rozróżnienia gwarancja zamienia się w źródło sporów.
Wymiana osób. Jeśli współpraca z konkretną osobą w zespole nie działa, powinieneś móc poprosić o jej wymianę bez długiego uzasadniania. U nas obowiązuje dwutygodniowa gwarancja satysfakcji i zastępstwo w ciągu 5 dni roboczych. Niezależnie od tego, z kim pracujesz, zapisz konkretny termin, bo „niezwłocznie” w praktyce oznacza „kiedy znajdziemy kogoś wolnego”.
Wykonawca, który rozumie MVP, sam zaproponuje próg jakości dopasowany do etapu: wysoki dla płatności i danych użytkowników, niższy dla eksperymentalnych ekranów, które mogą zniknąć po pierwszym teście. O tym, co w MVP jest „minimum”, a co już „produktem”, pisaliśmy w przewodniku czym jest MVP w tworzeniu oprogramowania.
Jakich zapisów o danych osobowych i bezpieczeństwie nie wolno pominąć?
MVP rzadko obywa się bez danych osobowych: rejestracja użytkowników, adresy e-mail, dane płatnicze, czasem dane wrażliwe. Jeśli wykonawca ma dostęp do środowiska produkcyjnego lub kopii danych w środowisku testowym, przetwarza dane osobowe w Twoim imieniu.
Umowa powierzenia przetwarzania. Artykuł 28 RODO wymaga, żeby przetwarzanie przez podmiot przetwarzający odbywało się na podstawie umowy, która określa przedmiot, czas trwania, charakter i cel przetwarzania oraz obowiązki stron. Wykonawca nie może korzystać z usług kolejnego podmiotu przetwarzającego, na przykład podwykonawcy, bez Twojej uprzedniej zgody, szczegółowej lub ogólnej, a w przypadku zgody ogólnej musi informować o zmianach i dać Ci możliwość sprzeciwu. To nie jest formalność dla dużych firm. To Twój obowiązek jako administratora danych.
Dane w środowiskach testowych. Zapisz, że kopie danych produkcyjnych nie trafiają do środowisk testowych bez anonimizacji, a jeśli z jakiegoś powodu muszą, to tylko za Twoją zgodą i na określony czas. To jedno zdanie w umowie i jedna z najczęstszych dróg wycieku danych w małych firmach.
Bezpieczeństwo kodu. Minimalne wymagania, które warto zapisać: aktualizacja zależności o znanych podatnościach w określonym czasie, brak sekretów w repozytorium, uwierzytelnianie wieloskładnikowe na wszystkich kontach z dostępem do produkcji, zgłaszanie incydentów w ciągu 24 godzin od wykrycia.
Cyber Resilience Act. Rozporządzenie UE 2024/2847 weszło w życie 10 grudnia 2024 roku. Obowiązki zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów mają obowiązywać od 11 września 2026 roku, a większość pozostałych wymagań od 11 grudnia 2027 roku. Rozporządzenie dotyczy produktów z elementami cyfrowymi wprowadzanych na rynek UE. Czysta usługa SaaS w wielu przypadkach będzie poza jego zakresem, ale aplikacja mobilna, oprogramowanie instalowane u klienta czy urządzenie IoT mogą się w nim znaleźć. Obowiązki spoczywają na producencie, czyli na Twoim startupie, a nie na wykonawcy. Jeśli Twój produkt może podlegać CRA, zapisz już teraz, że wykonawca dostarcza SBOM i wspiera obsługę podatności w okresie, w którym to Ty będziesz za nią odpowiadać.
Jak wygląda lista kontrolna umowy z partnerem do budowy MVP?
Poniższa tabela zbiera zapisy omówione wyżej. Użyj jej przy czytaniu wzoru umowy wykonawcy, zanim zaczniesz negocjować cenę. Kolumna „sygnał ostrzegawczy” pokazuje sformułowania, które powinny skłonić do pytań.
| Obszar | Zapis, którego szukasz | Sygnał ostrzegawczy |
|---|---|---|
| Prawa autorskie | Przeniesienie w formie pisemnej, z wymienionymi polami eksploatacji i zgodą na prawa zależne | „Przekazanie kodu”, „udzielenie licencji” bez przeniesienia |
| Moment przejścia praw | Z chwilą zapłaty faktury za dany okres | Po odbiorze końcowym i zapłacie całości |
| Łańcuch praw | Oświadczenie o nabyciu praw od wszystkich osób, w tym kontraktorów B2B | Brak zapisu o podwykonawcach i kontraktorach |
| Komponenty wykonawcy | Bezterminowa, nieodwołalna, przenoszalna licencja z prawem modyfikacji | Licencja „na czas trwania umowy” |
| Open source | Lista komponentów z licencjami (SBOM), zgoda na copyleft | Brak zapisu |
| Repozytorium i konta | Na spółkę od pierwszego dnia, wykonawca ma dostęp | Repozytorium u wykonawcy, przekazanie „po projekcie” |
| Rozliczenie | T&M z limitem miesięcznym, raport tygodniowy | Stała cena za niestabilny zakres |
| Wypowiedzenie | Tygodnie, bez kar, płatność za przepracowany czas | Kwartał lub dłużej, kary umowne |
| Przekazanie | Lista elementów, termin, godziny na transfer wiedzy | „Na warunkach do uzgodnienia” |
| Skład zespołu | Kluczowe osoby imiennie, zastępstwo w określonym terminie | Brak nazwisk, „odpowiednio wykwalifikowani specjaliści” |
| Jakość | Definicja ukończenia, gwarancja na błędy | Brak kryteriów lub korporacyjne wymagania nieadekwatne do MVP |
| Dane osobowe | Umowa powierzenia zgodna z art. 28 RODO, zasady dla danych testowych | Brak umowy powierzenia |
| Udziały za kod | Vesting, prawo odkupu, pełne przeniesienie praw | Udziały wydane z góry, prawa do kodu nieuregulowane |
Nie każdy zapis z tej tabeli musi być sformułowany dokładnie tak, jak go opisujemy. Ważne, żeby każdy obszar był w umowie świadomie uregulowany. Przed podpisaniem warto pokazać umowę prawnikowi znającemu prawo autorskie i branżę IT; koszt takiej konsultacji jest ułamkiem kosztu jednego miesiąca pracy zespołu.
Jakie są kluczowe wnioski przed wyborem partnera do MVP?
Wybór wykonawcy MVP to w dużej mierze wybór umowy. Portfolio i cena mówią, jak firma prezentuje się na początku współpracy. Umowa mówi, jak współpraca będzie wyglądać, gdy coś pójdzie inaczej, niż zakładano, a w startupie coś zawsze idzie inaczej.
Zapamiętaj sześć zasad. Po pierwsze, oceniaj wykonawcę po tym, jak łatwo będzie od niego odejść: wzór umowy, miejsce repozytorium i referencje od klientów, którzy odeszli, mówią więcej niż zrzuty ekranu. Po drugie, zacznij od krótkiego, płatnego discovery z przeniesieniem praw do wyników, zanim podpiszesz umowę na całe MVP. Po trzecie, przy niestabilnym zakresie wybierz time and materials z miesięcznym limitem i krótkim wypowiedzeniem zamiast stałej ceny. Po czwarte, zapisz przeniesienie praw autorskich na piśmie, z polami eksploatacji, z ciągłym łańcuchem od programistów i z przejściem praw przy każdej zapłaconej fakturze. Po piąte, załóż repozytorium, konta chmurowe i sklepy z aplikacjami na spółkę od pierwszego dnia. Po szóste, napisz klauzulę wyjścia teraz, kiedy obie strony są jeszcze zadowolone.
Jeśli szukasz partnera do zbudowania MVP, zobacz, jak pracujemy w obszarze tworzenia oprogramowania na zamówienie, albo umów rozmowę. Poproś nas o wzór umowy przed rozmową o cenie i sprawdź go z listą z tego artykułu. Discovery trwa u nas 1–2 tygodnie i kończy się zakresem, architekturą i planem pierwszych sprintów. Zapytaj przy tym, jak w umowie zapisujemy prawa do wyników tego etapu, i porównaj odpowiedź z tabelą powyżej.