Antyporadnik. Osiem sposobów na utopienie własnego startupu (cz. 1)

Dodane:

Michał Brodecki Michał Brodecki

Udostępnij:

Zaczynasz rozwijać aplikację: masz pomysł, przemyślałeś/przemyślałaś model biznesowy, idzie ci naprawdę nieźle. I właśnie teraz następuje ten moment: wybór technologii. To tak naprawdę prosta sprawa, ale można ją koncertowo… zepsuć. Jak utopić własny startup? Przeczytajcie antyporadnik.

1. Wybierz technologię, która absurdalnie wydłuży produkcję

Najlepiej taką, która kosztuje krocie – wtedy szybko pozbędziesz się pieniędzy, czyli doświadczysz jednego z najpopularniejszych powodów upadku startupów. To przecież nienormalne, że chcesz ukończyć swój produkt tak szybko, jak to możliwe. Rzuć sobie kłody pod nogi! Bądź masochistą i zrezygnuj z języka z gotowymi komponentami. Rób wszystko sam od nowa! 

Na przykład system logowania. To prawda, że są sposoby, żeby łatwo rozszerzyć uwierzytelnianie o Facebooka lub Google (choćby tu: rubygems.org). To samo dotyczy innych komponentów, takich jak np. płatności czy geolokalizacja. Ale nie dla ciebie droga na skróty!

2. Spraw, by konfigurowanie stało się syzyfową pracą

Wyobraź sobie, że chcesz nową sofę do pokoju. Masz dwie opcje. Pierwsza: kupisz sofę w całości i będziesz mógł usiąść na niej zaraz po tym, jak ktoś dostarczy ją do twojego mieszkania (w żadnym wypadku!). Druga: kupisz sofę w częściach i sam ją złożysz – śrubka po śrubce, deska po desce, najlepiej wykorzystując cały dostępny urlop… Po prostu musisz spędzić godziny na konfigurowaniu, zamiast od razu po zakupie uzyskać gotowy produkt, dzięki któremu po kilku minutach aplikacja będzie działa na serwerze.

Będziesz miał gwarancję, że twój programista do reszty osiwieje, martwiąc się o skomplikowany setup projektu. W ten sposób w żadnym wypadku nie będzie mógł skupić się na pracy i dostarczaniu funkcjonalności. I o to chodzi! 

3. Wspierająca społeczność? Powiedz „nie!” udogodnieniom!

Wśród języków typu opensource wsparcie grupy jest pod każdym względem ekonomiczne: kiedy programista chce rozwiązać problem, najpierw szuka odpowiedzi wśród społeczności. Jest wielkie prawdopodobieństwo, że ktoś już spotkał ten sam sam problem i go rozwiązał. To niekorzystna sytuacja – programista może dzięki temu zaoszczędzić swój czas na debugowaniu, a przecież nie o to nam chodzi!

„Praca w grupie” oznacza chętne dzielenie się swoim doświadczeniem i wiedzą. Brak takiej wymiany informacji na pewno obniży merytoryczny poziom pracy, a stąd już krótki dystans, który dzieli nas od osiągnięcia celu. Niestety, w większych miastach prężnie funkcjonują spotkania programistów (choćby Łódź Ruby User Group), jest też sporo dobrych merytorycznie blogów oraz profesjonalistów aktywnych na Twitterze. Baza wiedzy i przepływ najświeższych informacji jest naprawdę dużym zagrożeniem – nie dajmy się temu skusić. Nie tędy droga! 

4. Dojrzałość jest przereklamowana 

Niektóre języki bardziej odpowiadają potrzebom startupów, inne mniej. Wybierz taki, który nie sprawdził się już innym przedsiębiorcom – dzięki temu powielisz cudze błędy i przypieczętujesz upadek swojego projektu. Spójrz, jaką technologię wybrały startupy, którym się powiodło: Airbnb, Ask.fm, Basecamp, Bloomberg, Dribble, SlideShare. Teraz już wiesz, czego unikać.

Poradnik a rebours powstał – niestety – w oparciu o obserwacje własne.

Ciąg dalszy nastąpi.

Michał Brodecki

CTO w Binar Apps

Mgr inż. informatyki (Wydział FTIMS Politechniki Łódzkiej). Weteran Ruby – programuje od 6 lat. Ma żonę, jest tatą. Człowiek doświadczony życiowo – był sędzią piłkarskim w lidze okręgowej 🙂 Gra w gry i w planszówki, nie pogardzi dobrym filmem ani serialem. Zawodowo coraz częściej szkoli programistów: na Łódź Jungle Web, na 4Developers, podczas spotkań Łódź Ruby User Group.

 

 

Zdjęcie główne artykułu pochodzi z pl.depositphotos.com