W mojej drodze do zostania niezależnym twórcą aplikacji/solopreneurem/człowiekiem orkiestrą przeszedłem spory kawał drogi.
W moim poprzednim artykule (jest tylko jeden — dasz radę go znaleźć), podzieliłem się procesem tworzenia aplikacji solo i tym, jakie to trudne.
Patrząc wstecz, widzę, jak wielkim sukcesem była ta aplikacja — nie z powodu liczby płacących użytkowników (nie było ich wcale, teraz nie ma nawet niepłacących użytkowników 😊) — ale dlatego, że proces tworzenia tej aplikacji boleśnie pokazał mi, że posiadanie umiejętności programistycznych to za mało, a szczerze mówiąc, nie jest nawet aż takie ważne.
Nie zrozum mnie źle — bardzo przydaje się to, że potrafię programować, hostować swoje aplikacje na tanim VPS-ie itp. — ale aplikację można stworzyć, używając głównie narzędzi low-code/no-code. Powiedzmy, że tylko 5–10% procesu faktycznie wymaga kodowania.
Biorąc pod uwagę, jaką jestem osobą, miałem trudności ze znalezieniem sposobu — a raczej filozofii czy może frameworka (?) — na tworzenie aplikacji. To się zmieniło, kiedy natrafiłem na Pieter Levelsa (https://x.com/levelsio/). Dla mnie jego filozofia bardzo przypomina punk rock: prosta, szybka i nonkonformistyczna. Używa PHP i SQLite — żadnych wymyślnych frameworków next-gen, wydumanych wzorców programistycznych czy architektur. Jedna z jego aplikacji nawet nie była aplikacją; po prostu miał bramkę płatności z formularzem, gdzie użytkownicy przesyłali zdjęcia, a on ręcznie trenował AI, aby tworzyć zdjęcia w stylu, jaki chcieli. Dopiero kiedy ręczne robienie tego wszystkiego stało się zbyt czasochłonne, zautomatyzował proces.
Jak to się ma do tytułu?
Kiedy próbuję wymyślić, jak napisać nową aplikację, zawsze staram się podzielić ją na kroki i obszary, takie jak frontend, backend, logika, hosting itd. Na podstawie lekcji, które wyniosłem z doświadczenia, wiem, że nie powinienem przesadzać z wymyślnymi technologiami czy funkcjonalnościami. Najpierw trzeba stworzyć MVP.
Moje podejście polegało więc na tym, aby wziąć każdy najmniejszy element, jaki miałem, i zrobić go gównianie — wystarczy żeby działał. Zamiast frontendu, backendu, logiki, hostingu miałbym gówniany frontend, gówniany backend, gównianą logikę i gówniany hosting. Dopiero później, gdy cały ten stos kompostownika byłby gotowy — ale działał — mógłbym zacząć go dopracowywać. Np dodać porządniejsze style do frontendu, uwierzytelnianie do backendu itd.
TO JEST O WIELE TRUDNIEJSZE, NIŻ MYŚLISZ — przynajmniej dla mnie. Typowe podejście zakłada, że pierwsza wersja, którą robisz, jest gówniana, a potem ją ulepszasz. To nieprawda. Pierwsza wersja, którą robisz, to pół-ambitna wizja wymuszonych potencjalnych problemów, które próbujesz rozwiązać, zanim jeszcze zaistnieją, przy użyciu półpoprawnej architektury i myślenia o przyszłej skalowalności. Nie zaczynasz od “gównianego”; zaczynasz od „ambitnego i niedokończonego”. Następnie albo zaczynasz ciąć, aby zwiększyć tempo, albo zaczynasz krążyć w kółko, próbując zaimplementować lub naprawić coś, co nie jest potrzebne, by MVP działało. W efekcie albo spędzasz na tym za dużo czasu, albo się poddajesz.
Możesz pomyśleć, że świadomość tego wystarczy, aby uniknąć pułapki. Jednak umiejętność tworzenia gównianej aplikacji to naprawdę zdolność, którą trudno zdobyć. Liczba pomysłów, które leżą na cmentarzysku moich niespełnionych ambicji, jest ogromna. Za każdym razem, gdy coś piszę, łapię się na wpadaniu w pętlę while(true) dodawania lub poprawiania czegoś, co nie jest potrzebne dla SVP (shittiest viable product).
Nie mówię, że aplikacja musi być gówniana, ale kiedy masz gotowe SVP, możesz wtedy wziąć każdą jego część osobno, dopracować ją i uczynić mniej gównianą — albo nie, jeśli nie ma trakcji. Wtedy po prostu przechodzisz do następnego projektu. Mam też silne przeczucie, że czasami pierwsza wersja dowolnego modułu jest bardziej niż wystarczająca.
Jaki z tego wniosek?
Myślę, że wiele potencjału marnuje się przez kompulsywną potrzebę tworzenia czegoś „dobrego.” Tworzenie aplikacji to dość duże przedsięwzięcie — a może raczej mamy tendencję do niepotrzebnego komplikowania tego, ponieważ nie chcemy zrobić czegoś, co nie jest „wystarczająco dobre.”
A wiesz, co naprawdę nie jest wystarczająco dobre? Aplikacja, która nie działa, bo nie jest skończona. Zrobione jest lepsze od doskonałego. Tym samym życzę Tobie — i sobie — siły, by stworzyć coś gównianego.
Pamiętaj, że problemy i pomysły przedstawione w tym artykule są moje. Często piszę Ty/My/Wy ale to bardziej rozmowa z samym sobą niż pewność że te problemy dotyczą kogokolwiek innego niż ja. Ty możesz zmagać się z czymś zupełnie innym niż ja. Chciałbym jednak, żebyś wyniósł z tego artykułu jedną rzecz:
Jesteś wystarczająco dobry. Masz to, czego potrzeba. Wystarczy, że nie będziesz się poddawał.
Fail early, fail often, but always fail forward.
