Ta strona używa ciasteczek (cookies), dzięki którym nasz serwis może działać lepiej. Rozumiem
06.11.2019

Czy warto szukać programisty za udziały? Cienie bootstrappingu.

W dyskusjach z pomysłodawcami startupów i początkującymi przedsiębiorcami często powtarza się ten sam motyw: „mam świetny pomysł na aplikację ale nie umiem programować i nie mam budżetu na software house - zbuduję więc zespół pracujący za udziały a jak będzie sukces to zacznę płacić wynagrodzenia”. 
 

Pozornie - model idealny! Win win: sprawdzimy się, podziałamy hobbystycznie nad projektem, rozwiniemy go wspólnie bez inwestowania gotówki. Obie strony wnoszą coś od siebie, 50:50: jedna strona -  genialny pomysł, druga - pracę, obie ponoszą ryzyko i potem dzielą się zyskami. Brzmi jak gwarancja udanej współpracy, prawda? No nie bardzo. 

 

Bootstrapping, 


czyli model budowania biznesu z dostępnych zasobów - oszczędnie, lean, własnymi siłami i w modelu optymalizacji kosztów, to popularne podejście wielu founderów. Czasem jest jedyną opcją, a czasem świadomym wyborem i generalnie ma mnóstwo zalet, poważnie - jestem fanką bootstrappingu, zbudowaliśmy w ten sposób milionowy biznes nie wiedząc nawet, że robimy bootstrapping! Dlatego nie chcę, aby ten tekst miał negatywny wydźwięk dla bootstrappingu. 

Ale musisz pamiętać młody founderze, że umowy i plany sporządza się nie na dobre, a na złe czasy. A to z kolei oznacza, że planując rozwój swojego pomysłu musisz uwzględnić wszystkie sprawy, które mogą pójść nie tak. 

 

Co może nie wypalić w modelu pracy za udziały? 


prawdopodobny scenariusz budowania biznesu czy aplikacji za udziały będzie taki: zbierzesz kilka osób: programistów, grafików, może kogoś od marketingu, którzy zdecydują się na pracę za darmo. Bo umówmy się, na etapie pomysłu płacenie udziałami nie różni się zbytnio od płacenia banknotami z Monopoly albo kasztanami. Więc budujesz nieopłacany zespół przypadkowo zrekrutowanych hobbystów. Tak zbudowana ekipa będzie: a) słabo doświadczona - bo ci doświadczeni pracują już gdzie indziej za prawdziwe pieniądze albo robią własne biznesy, b) słabo zmotywowana - po początkowym entuzjazmie zaczną się wykruszać, rezygnować, odpuszczać.

 

Pojawią się problemy z egzekwowaniem zadań, bo skoro nie płacisz, to nie możesz też wymagać. To, co zostanie wykonane, będzie prowizorką sklejaną z różnych technologii, podejść, przez kolejnych dochodzących i odchodzących entuzjastów. Po roku-dwóch takiej szarpaniny stracisz nerwy, cierpliwość i wiarę w powodzenie projektu. 

 

Czarnowidztwo? Być może, ale zadaj sobie jedno podstawowe pytanie: 

 

Czy twój pomysł jest wystarczająco dobry?


Bo jasne, często zdarza się, że kiedy dobierze się dwóch lub trzech błyskotliwych cofounderów, o komplementarnych umiejętnościach i doświadczeniach, powstaje SUKCES. Taki kombinowany, patchworkowy bootstrapping jest chyba najczęściej spotykanym motywem historii udanych startupów. 

Ale kluczem są dwa słowa “cofounder” - czyli partner biznesowy, nie pracownik za udziały; i “komplementarny”, czyli będący na podobnym poziomie, a jednocześnie uzupełniający Ciebie i Twoje kompetencje. 

Od tego, jak mocne masz argumenty za swoim pomysłem zależy, kogo uda Ci się tą ideą porwać. Pracowników czy cofounderów? 

 headway-5QgIuuBxKwM-unsplash

Co wnosicie w projekt? 


Pomysłodawca wnosi pomysł. Pomysł, wbrew temu, co przyjęło się mówić w branży, nie ma praktycznie żadnej wartości. O sukcesie decyduje realizacja - a to właśnie z realizacją masz problem, dlatego szukasz programisty. Możesz skorzystać z różnych form finansowania: oszczędności, pożyczka od rodziny, kredyt, by zlecić napisanie aplikacji normalnie, za pieniądze. Z jakiegoś powodu chcesz jednak przekonać programistę, aby uwierzył w Twój pomysł równie mocno jak Ty i zainwestował w niego swój czas - czyli pieniądze, bo czas poświęcony na Twój projekt to jednocześnie czas, kiedy programista nie zarabia na projektach komercyjnych. Jeśli zatem Twój pomysł jest tak dobry, aby przekonać programistę do takiej inwestycji - czemu nie wziąć na niego kredytu, zostawiając sobie 100% udziałów? No właśnie. 

 

Ryzyko wcale nie rozkłada się fifty-fifty. Zwłaszcza przy porażce. 


Kiedy dobiera się dwóch founderów, układ jest jasny. Jesteśmy wspólnikami, razem prowadzimy projekt w kierunku bramki “break even point”. Mamy decyzyjność, klarowność ról, siłę wpływu. 

A jak to wygląda, kiedy “zatrudniasz” za udziały programistę? Układ się zmienia. Pracodawca-pracownik, wspólnik większościowy-wspólnik mniejszościowy? Kto ma decyzyjność w sprawie funkcji, a kto ma tylko klepać kod wedle specyfikacji? A marketing? Czy pozwolisz swojemu “programiście za udziały” decydować o koncepcji działań promocyjnych? O modelu biznesowym? I o finansach? Jeśli nie chcesz oddać decyzyjności, układ wcale nie jest w równowadze: bez decyzyjności programista ma w sumie niewielki wpływ na sukces lub porażkę przedsięwzięcia, więc jego ryzyko drastycznie rośnie. To nie jest win-win. 

 

Matematyka sukcesu 


Czyli układ “praca za udziały” jest niekorzystny dla pracownika. Spójrzmy na to jeszcze od drugiej strony. Powtórzę pytanie: jeśli Twój pomysł jest tak dobry, aby przekonać programistę do takiej inwestycji - czemu nie weźmiesz kredytu, zostawiając sobie 100% udziałów? 

Zwłaszcza, że udziały drożeją z każdym kolejnym kamieniem milowym. Skoro sam pomysł nie jest wiele wart, nie wnosisz do spółki jeszcze żadnego know-how, technologii, klientów ani kontraktów, to aby osłodzić programiście ryzyko musisz mu oddać sporo udziałów, powiedzmy 40%. Na początku drogi 40% z niczego to nadal nic, nie odczuwasz zatem większego dyskomfortu. Jednak za rok, dwa, kiedy aplikacja zbierze użytkowników i złapie trakcję, a jej wycena poszybuje do kilku milionów dolarów, 40% stanie się całkiem sporym kosztem pracy, którą mogłeś zlecić za kilkadziesiąt tysięcy złotych, prawda? 

Zwłaszcza, że jest kilka sposobów na zwiększenie wartości projektu jeszcze ZANIM powstanie. 


Powyższe dwa akapity prowadzą do uproszczonej konkluzji, że układ “udziały za pracę” jest korzystny dla foundera w scenariuszu… porażki, natomiast dla programisty - w scenariuszu sukcesu, na który ten ma jednak zdecydowanie mniejszy - biorąc pod uwagę rozkład udziałów- wpływ. Wnioski nasuwają się same. 

 

Co możesz zrobić? 


Mogłabym napisać “wyślij do nas brief”, ale nie o to chodzi. Przed Tobą jeszcze trochę pracy.

Zacznij od dokładnej analizy rynku i zbadaj potencjał pomysłu. Zrób lean canvas (więcej informacji o lean canvas: https://jcd.pl/lean-canvas-jak-uniknac-bledow). Pogadaj z ludźmi, przeprowadź wywiady - ale nie z rodziną i znajomymi, bo będą mili i wspierający, a nie o to chodzi. Dotrzyj do grupy docelowej, pogadaj o konkretnych problemach, które planujesz rozwiązań i zapytaj ile byliby skłonni zapłacić za narzędzie, które podniesie jakość ich życia w tej dziedzinie. Jeśli działasz w B2B podpisz listy intencyjne, zbierz potwierdzonych dostawców i kontrahentów. Wystaw landing page z formularzem zapisów na beta testy. Oszacuj, czy jesteś w stanie zbudować grupę odbiorców i jak duża może być. Inaczej mówiąc - odrób lekcje na sucho, zanim umoczysz kilkaset tysięcy i dwa lata życia. 


Bo takie dane pozwolą Ci zacząć rozmowę - z potencjalnym pracownikiem, cofounderem czy inwestorem - z innego poziomu. Uzyskasz nie tylko wstępnie przetestowany pomysł i konkretne wnioski do wdrożenia na etapie realizacji: o tym jakie funkcje, w jaki sposób komunikować, w którym kierunku rozwijać wartość, ale i proof of concept - dający lepszą pozycję negocjacyjną z inwestorem, który da Ci kasę, żebyś poszedł do profesjonalnego software house i zbudował produkt od początku porządnie.


Wtedy odezwij się do mnie i pogadajmy o specyfikacji ;) Żartuję. Wtedy sam będziesz wiedział, co i w jaki sposób chcesz zrobić. 


Po publikacji tekstu odezwała się do nas Monika Wycykał, ekspert w dziedzinie prawa startupów i IT, z sugestią pogłębienia tematu o aspekty prawne. Powstał z tego bardzo fajny wpis gościnny, który przeczytacie tutaj: https://jcd.pl/bootstrapping-aspekty-prawne.

Udostępnij:
Anna Karcz-Czajkowska

CEO w JCD.pl

Stwórzmy razem coś niesamowitego!

Napisz do nas!