Przedwstęp

Zakładam, że skoro kliknąłeś w ten artykuł, zastanawiasz się nad stworzeniem własnej aplikacji. Może masz w głowie pomysł z dużym potencjałem, który chcesz wprowadzić w życie. Znam ten ból. Poniższy artykuł przybliży Ci, jak to wygląda w praktyce.

Wstęp właściwy

Pewnego pięknego wieczoru zadzwonił do mnie telefon. Kolega, który wraz z drugim znajomym zajmują się oprawą DJską na weselach, zapytał, czy byłbym w stanie stworzyć dla nich aplikację. Chciał, aby klienci mogli zamawiać dedykacje przez telefon, zamiast przychodzić do stolika i (często już dość mocno pijani) zawracać im głowę.

Pomysł wydał mi się prosty i w ciągu godziny powstał pierwszy prototyp aplikacji, oparty na n8n jako backend i Airtable jako bazie danych. Frontend dla klientów to zwykły formularz w HTML, który pomógł mi wygenerować ChatGPT. Po krótkim szkoleniu dla kolegów, z tego gdzie pojawiają się zamówione utwory i jak tego używać – problem uznałem za rozwiązany.

Po kilku tygodniach i kilku imprezach otrzymałem feedback: “Działa to super, jest ogień i mega ułatwia pracę.” Natychmiast zacząłem myśleć: “Może zrobić z tego pełnoprawną aplikację i wreszcie zarobić te miliony?” Z tą optymistyczną myślą przystąpiłem do działania.

Rozdział 1 – Planowanie aplikacji: Od pomysłu do działania

Siedzę w programowaniu już kilka lat i zdążyłem nauczyć się, że jeśli zacznę pisać kod napompowany dopaminą, bez przemyślenia, jak to dokładnie ma działać, to nic dobrego z tego nie wyjdzie. Trzeba to wszystko zaplanować.

Przeglądając miliony różnych filmików na YouTube o budowaniu własnych aplikacji, trafiłem na kilku “Guru”, którzy mieli swoje sprawdzone sposoby na szybkie tworzenie i wypuszczanie aplikacji. W dużej mierze używali narzędzi no-code/low-code, ale najwięcej mówili o marketingu. Ja sercem jestem raczej twórcą niż sprzedawcą, więc generalnie treści marketingowe zostawiłem na “później”.

Jako programista backendowy stwierdziłem, że to, co mam teraz ułożone z klocków w n8n, przepiszę na kod i będzie super. Podepnę pod to bazę danych i rach ciach, API gotowe. Teraz tylko zostaje nam frontend.

Tutaj sprawa nieco się komplikuje, bo frontendowcem jestem słabym, ale przecież “Guru” polecali narzędzie no-code. Szybki research w temacie i pricing takiego np. Bubble mi się już nie podobał – niby można coś za darmo, ale tak naprawdę najlepiej płacić. Jestem osobą, która woli życie sobie raczej utrudniać niż ułatwiać, tym bardziej jeśli mogę na tym zaoszczędzić. Zdecydowałem się więc na AppSmith, darmowe, open-sourcowe narzędzie low-code do robienia takich mniej więcej paneli, które można by użyć do tego, czego ja potrzebuję.

Rozdział 2 – Zaczynamy działać

Uzbrojony w odpowiednie narzędzia i z, jak mi się wydawało, całkowicie rozpracowanym pomysłem na pierwszą wersję, zacząłem działać.

Na pierwszy ogień poszedł backend. Jak pisałem wyżej, doświadczenie pewne mam, to szło to w miarę gładko, nawet biorąc pod uwagę fakt, że starałem się pisać w miarę czysty kod. Bo przecież jak to ruszy i zacznie zarabiać, a ja kogoś zatrudnię, to żeby wstydu nie było.

Funkcjonalności leciały jedena za drugą: logowanie, jakieś cuda z OAuth i Azure, generowanie kodów QR dla gości, które kierują do formularza zamówień, customizowane formularze HTML, żeby każdy mógł swoje logo dodać, itd. Co prawda pojawiał się bug to tu, to tam, ale przecież wszystko naprawię. Dodatkowo, w ramach odpoczynku od pisania kodu, przesuwałem okienka w AppSmith, tworząc frontend. Tutaj modal, tutaj tabelka, tutaj lista. Co prawda lista zamówionych utworów, jak się odświeża co 5 sekund, to mruga, bo musi się przeładować, ale AppSmith inaczej nie umie. Logowanie było takie trochę na siłę, bo nie ma wbudowanego mechanizmu i raczej było to zhackowane, żeby działało, niż prawdziwe uczciwe logowanie. ALE przecież open source i za darmo – nie ma co narzekać. I pisałem sobie dalej…

Rozdział 3 – Zderzenie z murem rzeczywistości po raz pierwszy

Aplikacja szła do przodu. Już niby można się zalogować, już niby utwory można dodawać, ale ilość drobnych błędów i ograniczeń AppSmitha (i mojej nieumiejętności używania go) zaczęły się zbierać, dając ogólnie słabe wrażenie. ALE NIC TO!! Przecież się poprawi. Przecież nawet zrobiłem marketing! Z całej listy rzeczy, które kazał zrobić “Guru”, zrobiłem landing page z możliwością dopisania się do kolejki oczekujących na to arcydzieło i przeleciałem z 300 ogłoszeń na popularnym portalu ogłoszeniowym, pisząc do wszystkich wiadomość w stylu “Hej, widziałem Twoje ogłoszenia, tworzę właśnie aplikację, która może Ci się przydać…”. Z około 300 ogłoszeń na listę zapisały się 4 osoby, w tym 3 to znajomi… Marketing 1, Adam 0.

Zapał trochę opadł, ale apropos spotkania towarzyskiego ze szkolenia, w którym brałem udział, nadarzyła się okazja, żeby porozmawiać z ludźmi ode mnie mądrzejszymi. Pod mój niepohamowany potok słów wpadł pewien człowiek który wypuścił już kilka własnych produktów. Ów człowiek, w bardzo precyzyjny, wręcz chirurgiczny sposób wyjaśnił mi kilka rzeczy.

• Ilu zakładasz userów? – Około 100.
• Ile miesięcznie to może kosztować? – 50 zł.
• Chce Ci się dla 100 nietechnicznych klientów za 5000 zł miesięcznie robić support, utrzymanie, odpowiadać na maile z problemami, wystawiać faktury itd.? – Eee… no nie.

Na pytanie, co dalej, polecił mi zrobienie tego w open source i puszczenie za free. Zasugerował, że da mi to więcej w temacie doświadczenia, a nie uwalę się w coś, na czym nie zarobię, a będę miał pełno roboty przy tym. Zapytałem go też o to, jak to jest z tym marketingiem, bo ten “Guru” tak to podkreślał, powiedział jedno zdanie: “Dobrym marketingiem sprzedasz nawet słaby produkt, a najlepszego produktu nikt nie kupi, jak się o nim nie dowie.”

Rozdział 4 – Nowa nadzieja

Ok, dobra, jasne, rozumiem. I właściwie to mi ten front w AppSmith jakoś nie pasował. Poza tym, co “Ja nie zrobię?!”. Postanowiłem zaorać stary projekt i zacząć od nowa. Wszystko napiszę sam, do frontu użyję Blazora, bo zostaję wtedy w moim komfortowym C#, tylko użyję jakiejś biblioteki z komponentami, żeby to ładnie wyglądało.

Dodatkowo rezygnuję ze zcentralizowanej formy, gdzie klient loguje się do panelu na hostowanej przeze mnie stronie. Skoro open source i za darmo, to hostuj se pan sam… a najwyżej dodam usługę konfigurowania i hostowania za jakieś drobne $$$.

Lecimy. Backend poszedł łatwo, bo wiedziałem już, co i jak, bo przebrnałem przez to wcześniej. Teraz dodatkowe MOCNE postanowienie: TYLKO MVP, bez dodatkowych wodotrysków. Tylko zamawianie utworów i tyle! No może customizacja formularza – no bo przecież jakoś to muszą robić – ALE TYLKO TO!… ewentualne generowanie kodów QR, bo właściwie mam to już napisane z poprzedniej wersji – ALE NIC WIĘCEJ! – tak tak jasne.

Frontend w Blazorze… nie umiem we frontend, powinienem sobie to powtarzać jako mantrę. Zacząłem szukać biblioteki komponentów, oczywiście darmowej, bo to najlepsza cena. Szybko się okazało, że nie ma takiej, w której jest wszystko, czego potrzebuję. Znalazłem więc jakąś, która spełniała najwięcej oczekiwań, a o resztę będę się martwił później.

Ok, ale skoro to takie “zrób se to pan sam”, to jak ci ludzie będą to hostować? Może jakoś to w dockera zapakuję ładnie i będą tylko dockera odpalali… taaa już widzę, jak to robią. To może jakieś PWA z tego zrobię – tam nie działało to w ogóle. Ok, stanęło na tym, że kompiluję do EXEka. Ok, ale teraz inne pytanie: jak taki DJ na imprezie to będzie odpalał, to on to będzie chciał odpalać u siebie na laptopie, to jak te zamówienia będą do niego trafiać? To chyba muszę postawić jakiś serwer proxy i aplikacje klientów by się podpinały przy uruchomieniu do mojego serwera, który by przekazywał zamówiene utwory do nich… bardzo “niepiękne” rozwiązanie, ale czego nie robi się dla open source. Znalazłem nawet rozwiązanie o nazwie Portr, które miałbym dodawać do aplikacji i jeśli nie chcesz tego hostować sam (a już widzę, jak by to ktoś sam chciał hostować), to ja mogę Ci zaoferować dostęp do mojego serwera proxy i przez to możesz się łączyć, oczywiście za drobne $$$. I tak dalej, i tak dalej. Brzmi jakby miało być niepotrzebnie skomplikowane i generować milion problemów? Dokładnie takie było…

Rozdział 5 – Oram aplikację po raz drugi

Po kolejnej sesji mordowania się z proxy serwerem, zmęczony, zrezygnowany i przede wszystkim wkurzony, spojrzałem w lustro i stwierdziłem: “PIERDOLĘ”. Wyssała ta aplikacja ze mnie całe życie i radość tworzenia. Problem za problemem, a przecież to taka prosta aplikacja jest. Spojrzałem głęboko w siebie i zrozumiałem, że to nie aplikacja jest problemem, tylko ja.

Moja tendencja do dodawania niepotrzebnych w MVP funkcji, uparte utrudnianie sobie życia stosując narzędzia trudniejsze i niekoniecznie pasujące, ale tylko dlatego, żeby było za darmo, bo to uczciwa cena, i mentalność “CO?! JA NIE ZROBIĘ?” – no nie, nie zrobisz… osiwiejesz wcześniej, żona wyrzuci Cię z domu, bo i tak nie ma z Ciebie pożytku, bo tylko siedzisz przy laptopie i przeklinasz. Zrobiłem sobie małą przerwę od projektu z założeniem z tyłu głowy, że może jak nigdy więcej do niej nie wrócę, to świat się nie zawali.

Rozdział 6 – Oświecenie

Tak jak to zazwyczaj bywa, tematy, które chce odpuścić, znajdują drogę, żeby same się do mnie jeszcze raz przyczepić. Okazało się, że znajoma, która szkoli się na UX/UI designera, chętnie by powspółpracowała, żeby mieć coś do portfolio. Kurde, jak mam mieć UX/UI za darmo, to przecież świetnie, bo to najlepsza cena!

ALE ADAŚ! Ogarnij się, podejdźmy do tematu na spokojnie. Jak to zrobić, żeby to zrobić, a nie żeby to robić przez kolejne 6 miesięcy i się denerwować, a koniec końców tego nie zrobić? Pochyliłem pokornie głowę i wpisałem w Google “best no code app builder” i rozpocząłem proces researchu. Głównym warunkiem było, żeby pisać jak najmniej kodu… i żeby nie było za drogo. Ważyłem wszystkie za i przeciw: cena, możliwości, itd.

W końcu postanowiłem:

• Frontend – FlutterFlow: ładny, prosty, daje dużo możliwości. Cena… no ma cenę – nie rozmawiajmy o tym, ale łączy się ładnie z Firebase i, co ważniejsze, z Supabase.
• Backend – Supabase: Czyli backend instant. 99% tego, co ma robić ta aplikacja, to zapisywać do bazy danych albo z niej czytać, więc po co ja mam implementować to samemu, jak wszystko, łącznie z logowaniem i autoryzacją, mam tam out of the box? A i można self-hostować za darmo, a to przecież najlepsza cena.

Rozdział 7 – Dzień dzisiejszy

Aplikacja prawie gotowa, robię sobie od niej chwilkę przerwy, bo pomimo mocnego postanowienia, że to będzie tylko małe, gołe MVP, i tak gdzieś bokiem wcisnęły mi się niespodziewane funkcje.

Co do modelu biznesowego, to na początek planuję udostępnić ją za darmo i wziąć na klatę te 200 zł rocznie za mikr.us-a, na którym będę to hostował. Jak aplikacja chwyci chociaż trochę, to dorzucę tam może jakieś reklamy albo minimalny abonament rzędu 20 zł rocznie, żeby było na serwer i nie będę tego ruszał. Jak chwyci mocniej, to wtedy będę się zastanawiał dalej.

Słowo końcowe

Ostatnie około 12 miesięcy brutalnie udowodniło mi, że czym innym jest bycie programistą w dużej firmie jako jeden z drobnych trybików, gdzie pod nos dostaje taska w Jirze i muszę napisać jedną bardzo wąską funkcjonalność, która została już przemyślana przez analityka, ma przygotowaną warstwę graficzną przez UI/UXa i frontendowca. A czymś zupełnie innym jest tworzenie aplikacji od początku do końca całkowicie samemu.

Cytując słowa przeczytane gdzieś kiedyś: “Jak lubisz piec ciasta, nie otwieraj cukierni, tylko się w niej zatrudnij, bo jak otworzysz cukiernię, to nie będziesz piec ciast, tylko prowadzić firmę.” Taka prawda – musiałem się pogodzić z tym, że pisanie kodu to problem który trzeba minimalizować, i przestawić się bardziej na “tworzenie aplikacji”. Wyzbyłem się uprzedzeń do narzędzi no-code/low-code i przyznam, że bardzo je polubiłem. Zmieniłem mentalność z “JA NIE DAM RADY?!” na “Jak to zrobić szybko i wygodnie” i przede wszystkim przestałem bać się zainwestowania w odpowiednie narzędzia.

Co dalej? Wiem, że mimo iż nie chcę, to muszę nauczyć się marketingu. Bez tego nic się nie uda. Nie ma sensu robić najlepszej na świecie aplikacji, o której nikt się nie dowie. Będę dalej starał się poprawić wewnętrzną dyscyplinę, aby MVP było naprawdę minimum. Chciałbym również zrobić challenge “12 aplikacji w 12 miesięcy” aby zmusić się do szybkiego działania. Dzięki temu będę skupiał się na rozwiązaniach i popychał projekt do przodu, zamiast dodawać nowe funkcje. Co z tego wyjdzie? Zobaczymy.