Jak zbudować aplikację mobilną z Claude Code — pełny kurs

O czym jest ten film

1. Pełny, kilkugodzinny kurs budowy prawdziwej aplikacji mobilnej (na iOS i Androida) z pomocą Claude Code — od pustego folderu do zgłoszenia programu do App Store i Google Play, bez żadnego wcześniejszego doświadczenia w programowaniu mobilnym.
2. Konfiguracja warsztatu: konto Claude, edytor Antigravity z rozszerzeniem Claude Code, automatyczne wygenerowanie szkieletu projektu Expo/React Native oraz telefon jako urządzenie testowe przez aplikację Expo Go i kod QR.
3. Porównanie trzech dróg tworzenia aplikacji: Expo z React Native (wybór autora), Flutter z Firebase (wydajność kosztem narzuconego designu Google) oraz Capacitor (opakowana strona internetowa).
4. Autorski, pięcioelementowy schemat projektowania: funkcja rdzenna, pętla „działanie–nagroda”, funkcje dodatkowe, kontrola liczby ekranów i haczyk ściągający użytkownika z powrotem.
5. Obowiązkowa pętla testów przy każdej istotnej zmianie: przeglądarka → lustrzane odbicie telefonu → fizyczny telefon (haptyka, powiadomienia, ergonomia kciuka).
6. Praktyki higieny kontekstu i tokenów: polecenia /init, /clear i /compact oraz aktualizacja pliku claude.md po każdej większej iteracji.
7. Baza danych i logowanie w Supabase (z lokalną pamięcią podręczną) oraz funkcje AI — „trener osobisty” i cotygodniowe podsumowania — zbudowane na funkcjach brzegowych i API Claude.
8. Audyt bezpieczeństwa przeprowadzony gotowym, obszernym promptem, wykonywany dwu-, trzykrotnie na świeżym kontekście, bo naprawa jednej luki potrafi stworzyć inną.
9. Trzy zbudowane od podstaw aplikacje: tracker nawyków, licznik kalorii inspirowany Cal AI i pomodoro z rosnącym lasem — wraz z pełnym procesem projektowym, w tym grafiką generowaną przez modele obrazowe.
10. Publikacja: produkcyjny build przez EAS, konta deweloperskie Apple i Google, polityka prywatności hostowana w sieci i wypełnianie formularzy zgłoszeniowych z pomocą AI.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Zanim napiszesz pierwszą linijkę, ustal jedną funkcję rządną aplikacji

Na czym polega: Autor stosuje pięciostopniowy schemat: funkcja rdzenna (jedno zadanie, bez którego aplikacja przestaje być sobą), pętla „działanie–nagroda” (najlepiej krótsza niż 30 sekund), funkcje dodatkowe wspierające pętlę, kontrola „powierzchni” (maksymalnie 5–7 ekranów) oraz haczyk retencyjny, np. trójdniowe wyzwanie.

Jak stosować: Przed otwarciem edytora zapisz na kartce odpowiedzi na pięć punktów i przekaż je modelowi jako specyfikację — jeden dokładny opis zastępuje dziesięć poprawek w trakcie budowy.

Na co uważać: Początkujący zamiast jednej pętli robią dziesięć i wpadają w pułapkę „aplikacji z pięcioma milionami ekranów”. W świecie, w którym da się zbudować wszystko, wygrywa produkt robiący jedną rzecz naprawdę dobrze.

2.Expo i React Native jako bezpieczny wybór domyślny

Na czym polega: Jeden kod w JavaScripcie/TypeScripcie trafia na iOS, Androida i do przeglądarki; chmurowe buildy przejmuje Expo, a aplikacja na telefonie ładuje zmiany na żywo. Flutter daje wyższą wydajność, ale narzuca design Google; Capacitor to w istocie opakowana strona www.

Jak stosować: Jeśli dopiero zaczynasz, zostań przy Expo/React Native — najkrótsza droga od pomysłu do testów na własnym telefonie przez Expo Go i kod QR.

Na co uważać: Wybór stacku to kwestia przyzwyczajenia, nie obiektywnej wyższości. Nie próbuj optymalizować wszystkiego naraz — autor wprost mówi, że kto optymalizuje wszystko od razu, nie jest w niczym szczególnie dobry.

3.Nie rób ręcznie rzeczy, które model zrobi za ciebie

Na czym polega: Modele bywają trenowane na poradnikach, w których człowiek sam uruchamia komendy, więc często „oddają” ci pracę: każą wystartować serwer czy zainstalować zależności. Wystarczy poprosić: „zrób to za mnie w nowym oknie terminala” — to załatwia 80–90% roboty.

Jak stosować: Gdy w odpowiedzi widzisz instrukcję typu „uruchom komendę X”, odpisz: „wykonaj to w moim imieniu, w osobnym terminalu na moim komputerze, nie wewnątrz wątku”. Doprecyzowanie miejsca ma znaczenie, bo inaczej model potrafi uruchomić terminal w środku rozmowy i przepalić kod QR.

Na co uważać: Pełne uprawnienia dla agenta (tryb pomijania potwierdzeń) przyspieszają pracę, ale oznaczają, że model edytuje pliki bez pytania — bez wersjonowania w Gitie każda pomyłka zostaje z tobą.

4.Trójstopniowa pętla testów jest obowiązkowa, nie opcjonalna

Na czym polega: Każdą istotną zmianę sprawdza się trzykrotnie: lokalnie w Chrome, potem przez lustrzane odbicie telefonu, na końcu na fizycznym urządzeniu. Tylko ostatni krok pokaże wibracje, powiadomienia push, obcinające się ikony i to, czy główne funkcje mieszczą się w zasięgu kciuka.

Jak stosować: Zarezerwuj 10–15 minut na każdy przebieg i testuj po każdej dużej zmianie: po dodaniu bazy danych, po optymalizacjach, po audycie bezpieczeństwa. To frustrujące, ale nie ma innej drogi do pewności.

Na co uważać: Niektóre usterki (np. białe ikony paska systemowego na ciemnym tle) widać wyłącznie na telefonie — na komputerze wszystko może wyglądać idealnie. Zautomatyzowane testy modelu działają w przeglądarce, nie na urządzeniu.

5.Zarządzaj kontekstem: /init, /clear i /compact

Na czym polega: Polecenie /init tworzy plik claude.md — „kartę tożsamości” projektu ładowaną do każdej rozmowy, dzięki czemu model nie musi czytać wszystkich plików od nowa. /clear zeruje historię wątku i licznik tokenów, a /compact spina całą rozmowę w skondensowane streszczenie, gdy sesja robi się ciężka.

Jak stosować: /init zaraz po pierwszym działającym szkielecie; aktualizuj claude.md po każdej większej iteracji. /clear przed nowym etapem pracy (np. przed audytem bezpieczeństwa). /compact w okolicach 250–300 tys. tokenów, bo po przekroczeniu ~200 tys. jakości drobnych poprawek wyraźnie spada.

Na co uważać: Tokeny to realne pieniądze — każda funkcja to „przewalutowanie” środków z planu na produkt. Surowy klucz API trzymaj w pliku .env; wklejony do czatu trafi do historii rozmowy w wielu miejscach naraz.

6.Baza danych pociąga za sobą logowanie — zawsze idą w parze

Na czym polega: Samo dodanie chmury (tu: Supabase) nie wystarczy. Trzeba powiązać rekordy z konkretnym użytkownikiem, więc pojawia się ekran logowania, a aplikacja weryfikuje tożsamość przy każdym odczycie. Warto zachować lokalną pamięć podręczną: interfejs reaguje natychmiast, a dane synchronizują się z bazą w tle.

Jak stosować: Przy zakładaniu projektu w Supabase włącz automatyczne zabezpieczenie RLS, a na czas testów wyłącz wymóg potwierdzania e-maila. Modelowi przekaż URL projektu, klucz publiczny i parametry połączenia — resztę (schemat tabel, powiązania z identyfikatorami użytkowników) zrobi sam.

Na co uważać: Po dołożeniu bazy cały cykl testów trzeba powtórzyć od zera — zmienia się sposób działania aplikacji i pojawiają się nowe miejsca awarii. Lokalizacja serwera ma znaczenie: im dalej od użytkowników, tym większe opóźnienia.

7.Funkcje AI buduj na funkcjach brzegowych — i pilnuj kluczy

Na czym polega: Cotygodniowe podsumowania czy „trener osobisty” realizuje się tak: zaplanowana funkcja brzegowa (serwerless, włącza się na sekundę, gdy jest potrzebna) czyta bazę, pakuje dane i wysyła je z promptem do API Claude, a odpowiedź wraca do aplikacji jako powiadomienie.

Jak stosować: Zanim wbudujesz generowanie komunikatów na stałe, poproś model o 3–10 przykładowych wyników na sztucznych danych i ocen ich styl. Zadbaj o brak myślników (—), które natychmiast zdradzają autorstwo AI; emotikony zostaw tylko w tytułach.

Na co uważać: Każde wywołanie API kosztuje, a atakujący może celowo „palić” twoje tokeny, jeśli któraś operacja jest droga i niezabezpieczona. W aplikacji docelowej klucz developera powinien pozostać po stronie serwera, nie użytkownika.

8.Audyt bezpieczeństwa promptem — i to co najmniej dwa razy

Na czym polega: Zamiast ręcznego przeglądu kodu autor wgrywa obszerny prompt audytowy na świeżym, wyczyszczonym kontekście. Model wylicza dziesiątki punktów kontrolnych (zaszyte na stałe sekrety, brak walidacji po stronie serwera, domyślnie otwarte bazy, fikcyjne pakiety) i nadaje im rangi krytyczną/wysoką/średnią/niską.

Jak stosować: Uruchom audyt dopiero po zakończeniu pełnej pętli testów; każ model naprawić wszystko od góry do dołu, potem wyczyść wątek i puść ten sam prompt jeszcze raz. Drugi przebieg wyłapuje luki, które powstały przy naprawie pierwszych.

Na co uważać: Celem nie jest pełne bezpieczeństwo (nieosiągalne), lecz zebranie niskich owoców — tak, by atakującemu opłacało się szukać łatwiejszej ofiary. Przy aplikacji z danymi zdrowotnymi czy finansowymi ryzyko prawne rośnie o rząd wielkości; to nie jest porada prawna.

9.Projektuj obrazami: zrzuty ekranu i grafika generatywna

Na czym polega: Gdy funkcje działają, design to głównie zmiana stylów — i tu wystarczy pokazać modelowi wzór. Autor podaje zrzuty ekranu z Dribbble czy konkurencji, a dla pomodoro najpierw wygenerował makiety modelem obrazowym (GPT Image), kazał je pociąć na assety i odtworzyć w aplikacji „prawie piksel w piksel”, z autonomiczną pętlą zrzutów i poprawek.

Jak stosować: Zbuduj pętlę „zrób zrzut → wylicz nieścisłości → popraw” i każ modelowi przejść przez nią samodzielnie kilka razy. Do ikon i postaci (np. rosnące drzewka) generuj elementy pojedynczo, z usuniętym tłem — cięcie gotowych siatek grafik potrafi zająć agentowi wieki.

Na co uważać: Inspiracja to nie klon — koniecznie odbiegnij od wzorca, zanim opublikujesz produkt. Grafika generatywna bywa niedokładna (artefakty, niespójne drzewka w jednym zestawie), więc każdy asset trzeba obejrzeć okiem.

10.Publikacja to głównie papierologia — zautomatyzuj ją z AI

Na czym polega: Droga do sklepu prowadzi przez pliki app.json i eas.json, produkcyjny build w EAS, konto deweloperskie Apple (płatne) i konsolę Google Play, a także publiczną politykę prywatności i stronę wsparcia. Same zgłoszenie to serie zrzutów ekranu, opisów, kategorii i danych logowania dla recenzenta.

Jak stosować: Politykę prywatności, opisy i teksty promocyjne wygeneruj promptami i wystaw na własnej domenie (najlepiej tej samej, co adres e-mail firmy). Zrzuty ekranu i wypełnianie formularzy zleć modelowi. Przed pełnym wypuszczeniem skorzystaj z TestFlighta dla kilku realnych użytkowników.

Na co uważać: Apple nie gwarantuje przyjęcia aplikacji; recenzenci zwykle wskazują, co poprawić. Zignorowanie formalności (brak polityki prywatności, błędy w zgłoszeniu) to najprostsza droga do odrzucenia. Konto Google Play wymaga weryfikacji dostępu do fizycznego urządzenia z Androidem.

Redakcyjne tłumaczenie

Od zera do aplikacji na telefonie

To pełny kurs o budowaniu prawdziwej aplikacji mobilnej z Claude Code — od niczego do działającego programu na telefonie, niezależnie od tego, czy macie Androida, czy iPhone’a. Prowadzę firmę, która robi około 300 tysięcy dolarów miesięcznie i stoi niemal w całości na Claude Code; wydałem też kilka aplikacji webowych i produktów typu SaaS. Najczęstsza prośba, jaką dostaję, brzmi: „Jak przenieść tę wiedzę na aplikacje mobilne?”. Właśnie to pokażę. Na koniec tego materiału będziecie mieć działającą aplikację na własnym telefonie — nie makieta, nie emulator, prawdziwy program, który możecie pokazać ludziom, wraz ze ścieżką do App Store i Google Play. Doświadczenie w programowaniu mobilnym nie jest potrzebne. Jeśli potraficie wpisać angielskie zdanie w terminalu, dacie radę iść za mną krok w krok.

Plan jest taki: najpierw w niecałe dwie minuty pokażę gotową aplikację działającą na moim iPhonie. Potem ustawimy całe środowisko od zera — Claude Code, konfigurację mobilną i telefon jako urządzenie testowe. Wyjaśnię, jak w ogóle działają aplikacje mobilne i jakie frameworki się do nich używa, skupiając się na React Native i Expo. Następnie wspólnie zbudujemy całą aplikację i będziemy ją testować na telefonie w czasie rzeczywistym. Ćwiczenie powtórzymy jeszcze trzy, cztery razy, z rosnącym poziomem funkcjonalności, a na końcu przejdziemy przez zgłoszenie aplikacji do App Store i Google Play.

Pierwsze demo: tracker nawyków w pięć minut

Mam tu prostą aplikację do śledzenia nawyków. Pokazuję ją lokalnie na komputerze — interfejsowo jest to dokładnie ten sam program, który działa na telefonie; na desktopie po prostu wygodniej projektować. Widzicie ekran powitalny, ustawioną rozdzielczość mobilną, możliwość stworzenia pierwszego nawyku — powiedzmy trening trzy razy dziennie w wybranym kolorze — i taps, który stopniowo „napełnia” postęp. To funkcjonalnie to samo, co dziesiątki trackerów nawyków w sklepach z aplikacjami. Zbudowałem to w naprawdę niecałe pięć minut, z kilkoma porządnymi szablonami promptów.

Sposób tworzenia, który pokażę, polega na zbudowaniu najpierw wersji działającej w przeglądarce. Zaleta: projektujesz raz, wystawiasz w sieci, a potem przenosisz na telefon i optymalizujesz pod tablety. To najprostsza droga, choć nie jedyna. Zaczynam od trackera nawyków, bo ten typ aplikacji zawiera większość rzeczy, których ludzie oczekują: jakąś bazę danych, sposób jej odczytu i zapisu, interfejs, który z nią rozmawia, logowanie i „urocze” drobiazgi. Ale w żadnym wypadku nie jest to jedyny rodzaj aplikacji — można zbudować cokolwiek. Przykład: Cal AI, aplikacja, która łączy klasyczną funkcjonalność z AI — robisz zdjęcie jedzenia, a ono leci do API. (Informacja dodatkowa: Cal AI, licznik kalorii rozpoznający jedzenie ze zdjęcia, został według autora sprzedany za 50–100 mln dolarów; nabywcą był MyFitnessPal.) W tym kursie dojdziemy do poziomu, na którym jesteście w stanie budować właśnie takie produkty.

Progresja jest ważna. Zaczniemy od lokalnego trackera nawyków — bez API, bez bazy, wszystko trzymane w pamięci urządzenia. Potem dołożymy API, czyli cudzą funkcjonalność opakowaną w naszą aplikację. Następnie bazę danych, potem chmurę, logowanie i ekran autoryzacji — aż dojdziemy do architektury podobnej do tej aplikacji, która poszła za dziesiątki milionów. Tracker nawyków jest środkiem do celu, nie celem samym w sobie — więc gdy zobaczycie, że buduję „setny tracker nawyków”, wiedzcie, że o chodzi o naukę mechaniki, nie o produkt.

Konfiguracja Claude Code i edytora

Krok pierwszy: mieć Claude Code. Wchodzimy na stronę claude.ai, logujemy się mailem lub przez Google, wybieramy plan. Ja jestem na najwyższym, Maxie, ale do tego demo wystarczy Pro za 20 dolarów miesięcznie. Ktoś może krzywić się na cenę — dla mnie te 20 dolarów to prawdopodobnie najlepszy zwrot z inwestycji, jaki można dostać; używam Claude do praktycznie wszystkiego, a plan za kilkaset dolarów napędza firmę wartą 300 tysięcy miesięcznie. Moja rada: kupcie przynajmniej jeden miesiąc, nauczcie się z pierwszej ręki, a potem eksperymentujcie z modelami lokalnymi, jeśli chcecie ciąć koszty.

Zwykły czat to za mało — do programowania potrzebujemy Claude Code. Można z niego korzystać przez stronę, aplikację desktopową albo środowisko IDE; ja wolę to ostatnie, bo mam pełny dostęp do plików i dzięki temu zwykle wychodzą bardziej złożone aplikacje. Wszystkie te interfejsy to tylko „opakowania” wokół tego samego mózgu modelu.

Do tutoriala używam edytora Antigravity od Google. (Informacja dodatkowa: Antigravity to edytor kodu wydany przez Google pod koniec 2025 r., zorientowany na pracę z agentami AI.) Sciągamy wersję dla swojego systemu — u mnie plik dmg pod Apple Silicon — i przeciągamy do folderu Aplikacje. Po uruchomieniu zamykam panel agenta po prawej, wchodzę w rozszerzenia i instaluję wtyczkę „Claude Code for VS Code”. Od tej chwili ikona Claude pojawia się w całym edytorze. Jeśli po dwukrotnym kliknięciu w stronę nie otwiera się czat, w terminalu wpisujemy /login i wybieramy logowanie z subskrypcją — otworzy się strona autoryzacji. Chodzi o jedno: dopóki gdzieś na ekranie widać charakterystyczną ikonę Claude Code, wszystko gra.

Szybki sprawdzian. Klikam „otwórz folder”, tworzę katalog „example project” — chcę widzieć pliki, które Claude wygeneruje. Google uparcie promuje własne narzędzia, więc interfejs potrafi się przestawić; wtedy po prostu otwieram na nowo terminal Claude Code. Piszę: „zrób mi bardzo prostą stronę w bieżącym katalogu i ją otwórz”. Po chwili mam gotową witrynę. Dopisuję: „zmień powitanie na Nick” — i nazwa w nagłówku podmienia się sama. Zbudowanie czegoś nie jest trudne. Trudniejsze jest budowanie właściwych rzeczy i doprowadzenie ich do ludzi — i to też pokażę.

Trzy drogi do aplikacji mobilnej

Strona istnieje na moim komputerze. Ale żeby trafiła na telefon — a potem potencjalnie do setek tysięcy ludzi — trzeba pójść o krok dalej. Współcześnie robi się to na trzy sposoby.

Pierwszy, mój ulubiony: Expo z React Native. Jeden kod w JavaScripcie i TypeScripcie, z którego wystawiamy wersję na iOS, Androida, a nawet webową. Budowanie w chmurze przejmuje system Expo — zamiast żmudnej konfiguracji dostajemy zestandaryzowane narzędzie, które wie, jak przygotować paczkę do wdrożenia. Do tego ogromny ekosystem i przeładowywanie na żywo na urządzeniu, bezcenne przy testach, bo aplikację i tak odświeża się setki razy.

Drugi: Flutter z Firebase. Inny język — Dart, stworzony przez Google pod aplikacje na Androida — oraz autorski zestaw komponentów interfejsu. Google ma bardzo zdeterminowany system designu: przyciski i okienka we wszystkich aplikacjach na Androida wyglądają podobnie. Zaleta: pożyczasz gotowy design i szybko składasz całość. Wada: jesteś w nim uwięziony. W moim trackerze nawyków są szeryfowe fonty, własne zaokrąglenia, inna kapitalizacja, inne „odbicia” przy interakcji — z Material Designu tego nie dostaniesz. Flutter kompiluje się bezpośrednio pod procesory ARM, więc działa szybciej, a Firebase daje szybkie odczyty i zapisy na poziomie enterprise. Nie ma w tym nic złego — po prostu nie chcę w tym kursie zmuszać nikogo do niszowego języka, lock-inu w UI, który moim zdaniem jest ładniejszy u konkurencji, ani do przedwczesnej optymalizacji.

Trzeci: Capacitor. Być może jeszcze prostszy — budujesz stronę internetową i „opakowujesz” ją w warstwę pozwalającą wystawić ją do sklepu. Znane każdemu HTML, CSS i JavaScript; dostęp do sprzętu przez wtyczki. Tyle że tutaj uczymy się budować aplikacje, a nie strony. Kto optymalizuje wszystko naraz, zwykle nie jest w niczym wyjątkowy — Expo i React Native to dla mnie złoty środek między hiperzoptymalizowanym developmentem a ogólnym webem. Wiem, że programiści w komentarzach będą chcieli mnie zjeść. Trudno.

Środowisko mobilne: szkielet projektu i telefon w pętli

Zaczynam od polecenia /clear — kasuje historię rozmowy, obniża licznik tokenów i sprawia, że praca jest maksymalnie wydajna. Z folderu usuwam plik strony z poprzedniego demo, a potem piszę: „Chcę zbudować aplikację mobilną w Expo i React Native. Przygotuj mi środowisko”. W ustawieniach włączam też przełącznik pomijania uprawnień — Claude może wtedy działać bez czekania na moje potwierdzenia. Po chwili w folderze pojawia się kompletny, poprawnie zorganizowany projekt. Nie pobieram żadnego szablonu — model po prostu zna strukturę Expo.

Teraz: „stwórz prostą aplikację demo, jakiś tracker nawyków, i uruchom ją na moim telefonie”. Model przez półtorej–dwie minuty planuje, potem buduje. To nie jest magia — kilka prostych poleceń wystarczy, choć po drodze natkniecie się na techniczne zacięcia, które pokażę, gdy się pojawią. Programowanie z agentem to delegowanie części własnego myślenia — trzeba uzbroić się w cierpliwość. Jeśli wyskoczą błędy, nie panikujcie: Claude potrafi dziś naprawiać własne pomyłki, a z czasem pokażę, jak sterować jego samodzielnością przez tzw. system prompt — instrukcje ładowane do każdej rozmowy.

Aplikacja zgłasza gotowość: karta „Dziś”, karta „Zarządzaj”, zapis danych lokalnie. I prośbę: zainstaluj Expo Go ze sklepu, uruchom serwer, zeskanuj kod QR. Robimy to na telefonie: App Store, wyszukiwarka, „Expo Go”, instalacja, logowanie. Tu ważna rzecz — model każe mi samemu odpalić serwer poleceniem w terminalu. AI bywa tak trenowane, że „oddaje” nam robotę, bo w poradnikach, na których się uczyło, człowiek robił to ręcznie. Jedna z najbardziej opłacalnych zmian nawyków to odpowiadanie: „zrób to za mnie w nowym oknie terminala”. To załatwia 80–90% pracy.

Model otwiera terminal, pojawia się wielki kod QR. Skanuję go aparatem, otwieram link, wpisuję kod dostępu — i tracker nawyków uruchamia się na moim telefonie. Na dole ekranu widać jakiś błąd „uncaught in promise” — ignoruję go, patrzę na sedno: aplikacja działa, licznik się napełnia, po zrobieniu wszystkiego pojawia się komunikat „wszystko zrobione na dziś”. Pokazuję to przez aplikację lustrzaną dla iPhone’a, ale namawiam was do testów bezpośrednio na sprzęcie. Na telefonie odkrywa się rzeczy, których nie widać z kodu: dziwne gesty przeciągania, ukryte funkcje. Ja np. dopiero na telefonie zauważyłem, że aplikacja ma osobną stronę tworzenia nowego nawyku.

Jak zaprojektować dobrą aplikację: pięć kroków

Wiemy już, że da się zbudować aplikację. Skoro technologia pozwala na wszystko, sedno sprowadza się do skierowania tej mocy we właściwą stronę. Każda dobra aplikacja przechodzi przez pięć kroków — omówię je na przykładzie trackera nawyków.

Po pierwsze, funkcja rdzenna. Jedna rzecz, która — gdybyśmy z aplikacji usunęli wszystko inne — nadal czyniłaby ją tą aplikacją. W trackerze nawyków: stworzyć nawyk, tapnąć go i zapisać fakt wykonania. To cała esencja.

Po drugie, pętla podstawowa: cykl, który mapuje działanie na nagrodę, najlepiej krótszy niż 30 sekund. W grach mobilnych ta pętla jest ciaśniejsza i bardziej dopaminowa niż w trackerze kalorii, ale mechanika jest ta sama: użytkownik tapnie, aplikacja nagradza. Nagrodą może być dźwięk dzwonka, animacja, konfetti spadające po osiągnięciu celu. Polecam aplikację Opal, blokująca mi media społecznościowe w określonych godzinach — każdy dzień blokady ulepsza twój „klejnot”, aż po dwóch tygodniach lśni jak ametyst. Ludzie są istotami dotykowymi — używajcie wibracji. Pętlę można komplikować: stawki pieniężne, partnerów do rozliczania się. U nas zostanie prosta.

Po trzecie, funkcje dodatkowe — wszystko, co owija się wokół rdzenia, nie zmieniając go: historia wykonanych nawyków z wykresem, personalizacja (nawyk „zero-jedynkowy” raz dziennie vs. liczony, jak osiem szklanek wody), funkcje społecznościowe typu „dodaj znajomego i dostawaj powiadomienia o jego postępach”. Rozszerzają zasięg, ale nie ruszają pętli.

Po czwarte, kontrola powierzchni. Początkujący z ekscytacji robią dziesięć funkcji rządnych, sto pętli, tysiąc dodatków — i nagle aplikacja ma pięć milionów ekranów. W świecie, w którym można wszystko, wygrywa zrobienie jednej rzeczy naprawdę dobrze. Ekranów powinno być garść; użytkownik ma zrozumieć aplikację po jednym przejściu, bez zdobycia doktoratu z jej obsługi.

Po piąte, haczyk retencyjny: niedokończony stan, do którego trzeba wrócić. Trzydniowe wyzwanie zmusza do otwarcia aplikacji trzy razy w ciągu 72 godzin. Można też zaplanować „meldunek” przed snem: stworzyłeś nawyk rano? Wieczorem tapnij, potwierdź. Cel rozwoju aplikacji nigdy nie jest „użyj raz i odinstaluj” — każdy, kto tak twierdzi, kłamie. Cała praca polega na tym, by ludzie wracali.

Mając te pięć elementów, mamy zdefiniowany zakres MVP — wersji minimalnej, którą można oddać modelowi do zbudowania.

Budowa trackera nawyków: od specyfikacji do telefonu

Wracam do okna Claude Code i wpisuję /init. To polecenie tworzy plik claude.md — „kartę tożsamości” projektu: architekturę, motyw, stan, ścieżki. Dzięki niemu model przy każdym starcie wie, co buduje, bez czytania wszystkich plików. Oszczędza to tokeny — a plan taryfowy zużywają właśnie tokeny — i czas. Potem /clear i licznik na nowo spada do zera.

Żeby nie klepać specyfikacji palcami, dyktuję ją narzędziem do transkrypcji mowy. Treść: używam frameworku składającego się z funkcji rządnej, pętli, funkcji dodatkowych, kontroli powierzchni i haczyka retencyjnego. Funkcja rdzenna: tworzenie i śledzenie nawyków. Pętla: każde utworzenie lub wykonanie nawyku zostaje nagrodzone bodźcem wizualnym, wibracją i dźwiękiem; po trzech dniach wyzwania — dodatkowa nagroda. Dodatki: dziennik z grafikiem konsekwencji, kilka typów nawyków (dzienny i liczony). Powierzchnia: maksymalnie 5–7 ekranów. Haczyk: wyzwania plus powiadomienia push raz lub dwa razy dziennie — „pukanie do drzwi”, pytanie o nawyk zapowiedziany rano.

Wklejam to do rozmowy. Testy przenoszę na czas budowy do Chrome — funkcjonalnie to samo, a powiększenie jest dużo lepsze; na telefon wrócę na końcu, bo haptyki i dzwonka nie da się usłyszeć w przeglądarce.

Model mapuje framework na aplikację: sześć ekranów — onboarding, pierwszy start (wybór trzech nawyków i start trójdniowego wyzwania), „Dziś” jako codzienna lista kontrolna czyli sama pętla, „Historia” z kalendarzem i wykresem konsekwencji, „Zarządzaj” do dodawania i konfiguracji nawyków, „Wyzwania” i „Ustawienia” (powiadomienia, motyw). Pętlę wzmocni wibracją, dźwiękiem i wybuchem konfetti przy ukończeniu, do czego użyje biblioteki reanimated. Mógłbym wydziwiać nad wyborem bibliotek — konfetti obciąża procesor — ale na tym etapie chcę tylko dowodu, że koncept działa.

Claude proponuje podzielenie prac na fazy. Model ma tendencję do oszczędzania tokenów i wysiłku, więc zawsze odpowiadam: „róbmy wszystko naraz, fazy od pierwszej do czwartej; skończywszy, otwórz w Chrome”. Po około pięciu minutach myślenia sam otwiera karty przeglądarki — to jego wewnętrzna pętla testów. Pod adresem localhost:8081 widać lokalny serwer z naszą aplikacją. Szkielet działa: wybór nawyków (ćwiczenia, medytacja, woda osiem razy dziennie), przycisk trójdniowego wyzwania, dolne zakładki. Trochę tekstu jest niewidoczne — kolor fontu zlał się z tłem — ale rdzeń żyje: tapnięcia napełniają licznik, słychać dzwonek, po wykonaniu wszystkiego pojawia się „wszystko zrobione na dziś”, a odznaczenie też działa, bo pomyłkowy tap też się zdarza.

Teraz druga tura dyktowanych poprawek: potrzebuję widoku deweloperskiego do przemieszczania się po dniach wyzwania — chcę zobaczyć, co dzieje się po trzech dniach, a nie tylko ufać, że działa. Font: znacznik wyboru i część tekstów w historii i zarządzaniu są niewidoczne. Brakuje tworzenia własnych wyzwań — nie chcę żyć z gotowych. Statystyki: po jednym dniu ćwiczeń aplikacja pokazuje 3%, co pasuje raczej do okna 30-dniowego niż 7-dniowego — sprawdź. Teksty na historii łamią się i wyrównują do lewej — brzydko. Przypomnienia: chcę ustawiać godzinę osobno dla każdego nawyku, zamiast jednej dziewiątej rano dla wszystkich. Dorzuć ekran wyjaśniający w trzech zdaniach, jak aplikacja działa. „Przejdź wszystko od góry do dołu, wdroż i otwórz w nowej karcie”.

Efekt: naprawione fonty i statystyki, przypomnienia per nawyk, kreator własnych wyzwań i narzędzia deweloperskie — symulacja ukończenia wyzwania, wymuszenie ukończenia, reset onboardingu, czyszczenie danych. Onboarding zyskał stronę „jak to działa” z przyciskiem pominięcia. Wybieram czytanie, spacer i zdrowy posiłek (testują dwa typy nawyków), startuję wyzwanie. Dzwonek — uwierzcie na słowo — jest zachwycający, konfetti mogę odpalać w kółko. Historia mieści teraz serię, rekord i 30-dniową średnią w jednej linii, konsekwencja pokazuje 14% w oknie tygodnia i aktualizuje się na żywo. W zarządzaniu wybieram ikonę, wpisuję „poranny bieg” jako nawyk liczony z celem pięciu, ustawiam przypomnienie na dwunastą — tapnięcie włącznika przełącza przypomnienie. Potem symuluję ukończenie wyzwania: korona, trofeum, „trzydniowe rozpędzanie, dzień pierwszy ukończony, trzy nawyki policzone”. Aplikacja proponuje utworzenie kolejnego wyzwania — wybieram długość i nawyki, startuję. Od nowa nawyk wisi u góry strony „Dziś”.

Trzecia tura: sekcja nowego wyzwania ma dziwny margines — pewnie niewidoczny kontener w tle; nawyki liczone z „3 z 3” pod spodem prezentują się osobno od reszty — proszę o jeden wiersz; karty na historii są ciasne pionowo — dodajcie oddechu; w zarządzaniu dorzuć pięć ikon, żeby był pełny rząd, i wielką literę w „Morning Run”; przy przypomnieniach brak potwierdzenia ustawienia, a ramka urywa się bez zaokrąglenia — połącz to w spójną całość; pola wyboru w edycji wyzwania wyglądają, jakby style się nie załadowały — napraw. To jest te 20% dające 80% efektu.

Czas na telefon. Proszę: „uruchom serwer Expo w nowym oknie terminala”. Koniecznie „w nowym oknie”, bo inaczej nie zobaczę kodu QR. Uruchamiam, skanuję — a tu „uncaught in promise” i błąd z odczytem pamięci. Kopiuję całość komunikatu, wklejam do Claude: okazuje się, że biblioteka zapisu w wersji 3 nie współpracuje z Expo Go — trzeba wersji 2.2.0. Zamykam serwer (Ctrl+C), odpalam ostatnią komendę strzałką w górę, skanuję ponownie — błędów brak, tracker działa lokalnie na telefonie. I tu ważne: ikony emoji obcinają się o połowę, u góry zegar nachodzi na datę — brak marginesu pod systemowym paskiem iPhone’a. Zapisuję uwagi do modelu i idę dalej: powiadomienia i dźwięki działają, animacja jest ładna, historia trzyma daty. Prośba o zgodę na powiadomienia pojawia się dopiero przy próbie ustawienia przypomnienia — niskie tarcie, dobrze. Wymuszam ukończenie wyzwania — korona i licznik działają. Tworzę własne wyzwanie ze zdrowym posiłkiem.

Ostatni test musi być na telefonie, bo używanie komputera i telefonu to dwie różne rzeczy: myszka sięga wszędzie, kciuk nie. Główne funkcje muszą mieścić się w jego zasięgu, przewijanie musi działać tak, jak się spodziewasz, długie przytrzymanie musi coś robić. Ponaczykałem, powpoprawiałem — i szczerze: to jest pełne 80/20 i już lepszy tracker nawyków niż większość tego, co jest na rynku. Zbudowałem go za mniej więcej połowę sesji Claude, w ramach subskrypcji za 20 dolarów. Zapisuję zmiany. Pierwsza wersja gotowa.

Po dopracowaniu: claude.md i GitHub

Gdy aplikacja dojrzeje, zrób dwie rzeczy. Najpierw zaktualizuj claude.md — to nie jest już wersja beta, tylko pełnoprawne MVP, a plik ten jest ładowany do każdej przyszłej rozmowy, więc powinien opisywać całą nową funkcjonalność. Po drugie, wypchnij projekt na GitHuba. To platforma do wersjonowania — place na kod w internecie, które pamiętają też każdą zmianę. A to bezcenne, gdy AI grzebie w twoim repozytorium, co mu się żywnie podoba: działa aplikacja, wprowadzasz poprawki, coś się sypie — i bez łatwego powrotu do wcześniejszej wersji oraz dzielenia się nią z zespołem jesteś w poważnych tarapatach.

Konto zakłada się w minutę — e-mail, czasem telefon, podwójna weryfikacja. Potem wystarczy napisać: „utwórz repozytorium dla tego projektu, dodaj README i wypchnij”. Model loguje, tworzy, publikuje. Mój projekt nazwał „example project”, więc każę zmienić nazwę na „habit tracker” — i katalog też. Zawsze nazywajcie rzeczy; po otwarciu folderu sesja się zresetuje, o czym warto pamiętać. Na GitHubie widać cały kod i Claude, co zabawne, dopisuje siebie jako współtwórcę: „Nick robi jednak ciężką robotę, wierzcie mi”. Zmiany z dwóch minut temu widać w historii — możecie cofnąć każdą.

Baza danych i logowanie w Supabase

Mamy aplikację działającą lokalnie na komputerze i telefonie. Ale wszystkie dane — nawyki, ustawienia — siedzą w pamięci urządzenia. Gdybym wysłał ją komuś, ta osoba nie zobaczyłaby moich danych. Żeby aplikacja obsłużyła wielu ludzi i trzymała dane niezależnie od sprzętu (telefon i komputer ciągnące tę samą zawartość), potrzebna jest baza danych. Baza to w gruncie rzeczy dysk twardy hostowany gdzie indziej — a skoro gdzie indziej, trzeba z nią jakoś rozmawiać; tu wchodzą języki typu SQL. Kiedyś była to magia: moja pierwsza aplikacja w firmie 1SecondCopy, która urosła do ponad 90 tysięcy dolarów miesięcznie, robiąca rzecz prostszą niż ten tracker, zajęła mi trzy tygodnie — z czego dwa i pół tygodnia dłubałem w schemacie bazy. Dziś to тридцать sekund.

Wybieram Supabase. Baz jest milion, a mój wybór to kwestia przyzwyczajenia: gdy budujesz wiele aplikacji, z czasem osiadasz na jednym zestawie narzędzi, który znasz, i już nie chce ci się niczego innego. To samospełniająca się przepowiednia — niekoniecznie najlepszy stack, po prostu twój. Zasady pokażę na Supabase, ale przeniosą się na dowolną bazę.

Architektura: aplikacja rozmawia z urządzeniem, a urządzenie — z chmurą. I tu kluczowa rzecz: ta warstwa wymaga powiązania danych z konkretnym użytkownikiem. Nie wystarczy dorzucić bazy — potrzebny jest ekran logowania. Aplikacja wysyła login, baza weryfikuje, po czym zwykły ruch danych między urządzeniem a chmurą rusza. Taki układ jest najwydajniejszy, bo łączy lokalny podgląd (dane ładują się natychmiast) z okresową synchronizacją. Najlepsze: nie musicie znać się ani na bazach, ani na autoryzacji — Claude zrobi większość, o ile wybierzecie dostawcę, który obsługuje to kompleksowo, jak Supabase.

Dyktuję prośbę: „chcę dodać bazę danych wraz z lokalną pamięcią podręczną dla szybkiego działania; użyjemy Supabase; potrzebna też autoryzacja, żeby wiadomo było, który użytkownik czyta które dane; przeprowadź mnie przez proces”. Można po prostu poprosić model o pomoc. Model podmienia lokalny zapis na wywołania API i dorzuca zabezpieczenia, żeby nikt pod moim loginem nie dobrnął do moich danych.

Proponowana architektura: logowanie e-mailem i hasłem (opcjonalnie OAuth, czyli wejście jednym kliknięciem przez Google), baza Postgres na nawyki, ukończenia i wyzwania — to jest wbudowane w Supabase; lokalna pamięć jako pierwsza warstwa odczytu, żeby interfejs był błyskawiczny, a baza dosypywała dane w tle; ekran onboardingu zastępujemy ekranem logowania i rejestracji. Zgadzam się na e-mail z hasłem i mówię: „Nie mam jeszcze Supabase, założę projekt równolegle — zrób wszystko, co możesz bez tego”.

W Supabase: darmowe konto, nowy projekt, nazwa „habit tracker app”, silne hasło bazy, region — lokalizacja ma znaczenie, bo im dalej serwer od użytkowników, tym większe opóźnienia. Obowiązkowo zaznaczam automatyczne włączenie RLS, czyli bezpieczeństwa na poziomie wierszy. Po trzech minutach wszystkie usługi raportują zdrowie — nie musicie wiedzieć, co oznaczają. Z panelu kopiuję URL projektu, klucz publiczny i parametry połączenia i wklejam wszystko do Claude. Trenowany na starych danych model czasem zakłada, że schemat bazy trzeba uruchamiać ręcznie — a zwykle wystarczy dać mu pełny dostęp, a zrobi to sam. I robi: w edytorze SQL powstają tabele.

Schemat — czyli zbiór tabel — wygląda tak: wyzwania (identyfikatory użytkownika i nawyku, nazwa, data startu, czas trwania, flagi ukończenia i odebrania nagrody), ukończenia, nawyki i dodatkowo profile z danymi użytkownika. Kiedyś to wszystko wymyślało się ręcznie i żmudnie wiązało identyfikatory między tabelami; dziś model robi to automatycznie, bo —jak stwierdzić — logiczne jest, że nawyk ma nazwę, emoji i jeden z dwóch typów. W panelu autoryzacji wyłączam wymóg potwierdzania adresu e-mail: zbędny krok utrudniający testy.

Test pełnego przepływu: kilka crashy przed startem to norma, aplikacja sama się „wyżarza”. Rejestracja, onboarding — ta sama funkcjonalność, tylko owinięta w logowanie, z bazą pod spodem. Wybieram czytanie, spacer, dziennik, startuję wyzwanie. A w panelu Supabase widać nowego użytkownika z przypisanym identyfikatorem, a w edytorze tabel — jego nawyki: read, walk, journal, asdf. Dane są żywe: zmieniam godzinę przypomnienia w aplikacji — w bazie też. Usuwam nawyk w aplikacji — liczba rekordów w tabeli spada z czterech do trzech, bo Claude dopisał kod usuwający też po stronie bazy. Mogę też edytować wprost w panelu: przełączam przypomnienia na włączone, odświeżam — gotowe. Tabela ukończeń zapisuje dokładną datę, licznik i identyfikator nawyku: za trzy miesiąc aplikacja odtworzy z tego, co i kiedy robiłem. To nie jest wyczerpujący przewodnik po bazach, ale wszystkie bazy SQL działają dziś według tego samego schematu: tabele powiązane z identyfikatorami użytkowników przez autoryzację i panel administracyjny, w którym można np. założyć konto komuś, kto ma problem z rejestracją.

I znów: komputer → Expo → telefon. Trzeba sprawdzić, czy rejestracja i tworzenie nawyków odbijają się nie tylko w Chrome, ale i na telefonie; czy haptyka gra, czy ikony się nie obcinają. Ta pętla testów jest obowiązkowa, co sessję. Istnieją obiecujące metody automatycznego testowania na komputerze, ale nie znam żadnej, która testowałaby na telefonie — więc zarezerwujcie dodatkowe 10–15 minut. Przy błędach: nagrajcie głosówkę, opowiedzcie po ludzku, co się dzieje.

Funkcje AI: trener i cotygodniowe podsumowania

Moglibyśmy publikować, ale obiecuję wyższe poziomy funkcjonalności. Dorzucę dwie funkcje oparte o zewnętrzne usługi AI pracujące w tle.

Pierwsza: inteligentny trener. Okresowo — codziennie lub co tydzień — analizujemy w bazie serie i konsekwencję i wysyłamy spersonalizowane wiadomości: „Śpisz bez zarzutu od 14 dni, brawo, ale nawodnienie kuleje — oto szybki trik”. Podobne rzeczy widzę w aplikacji mojej opaski Whoop i coraz więcej aplikacji będzie je dodawać. Druga: cotygodniowe lub comiesięczne podsumowania generowane przez AI: „Największa konsekwencja: medytacja, 92%; ćwiczenia siłowe załamały się w środku tygodnia; wynik 19% przy celu 33%”.

Architektura wygląda tak: aplikacja na telefonie cyklicznie odpala funkcję brzegową Supabase — drobne narzędzie serwerless, które budzi się na sekundę, wykonuje pracę i zasypia. Alternatywą jest serwer włączony 24 godziny na dobę; funkcja brzegowa jest tańsza i wystarczająca w naszej skali. Funkcja czyta bazę — nawyki, ukończenia, serie — pakuje to w zestaw danych i wysyła wraz z prostym promptem do API Claude: „oto przykład wiadomości trenera; twoim zadaniem jest przejrzeć dane użytkownika i napisać podobne”. Odpowiedź ląduje w bazie jako komunikat trenera, wraca przez funkcję brzegową do aplikacji i tam ukazuje się jako powiadomienie push i trwały widok wewnątrz aplikacji. Dokładnie tak działają wszystkie zintegrowane usługi w aplikacjach mobilnych: aplikacja, serwer, baza i jakieś API. Zawsze ten sam krąg — będzie się powtarzał i przy kolejnych aplikacjach.

Wgrywam obie funkcje i zrzut diagramu architektury — choć Claude pewnie wymyśliłby to samo. Dyktuję: „wdroż obie funkcje, backend ma być Claude, żądania mają iść przez Supabase, użyj rozsądnych modeli — niech to będą Sonnety — zaktualizuj bazę i dopilnuj zgodności z diagramem”. Model ładuje dokumentację funkcji brzegowych; po wciśnięciu Ctrl+O widać szczegóły tego, co robi pod maską — ja nie chcę znać się na każdym szczególe, chcę tylko wiedzieć, że model ma pełny kontekst. Licznik tokenów skoczył z 20 tysięcy do 51 tysięcy: te pierwsze 20 to podstoga każdej sesji (pliki, claude.md, wbudowane narzędzia), reszta to już realne zużycie. Funkcje nie są darmowe — wymieniamy dwie waluty, tokeny i pieniądze, na funkcjonalność.

Dygresja o przyszłości SaaS: myślę, że niedługo nikt nie będzie chciał szablonowych produktów. Większość aplikacji stanie się „bezgwiazdkowymi” backendami, do których użytkownik podepnie własny front, a AI dopasuje wygląd i zachowanie do jego gustu — może jako dodatkowy plan taryfowy. Kiedyś zespoły marketingowe robiły „magnesy na leady”: szablonowe PDF-y pisane raz i rozsyłane wszystkim, bo nikt nie był w stanie personalizować. Dziś magnesy te przestają działać — każdy może przecież zapytać AI i dostać odpowiedź szytą na miarę. To samo spotka gotowe aplikacje SaaS.

Model kończy: baza z komunikatami trenera i podsumowaniami, funkcje brzegowe, strona aplikacji. Prosi o klucz API Anthropic. Każda zewnętrzna usługa wymaga uwierzytelnienia — klucz API to w praktyce hasło. Zakładam go w konsoli Anthropic (ta funkcja będzie kosztować, to API), wklejam — choć model słusznie upomina się, by nie wklejać kluczy otwartym tekstem w czacie; właściwe miejsce to plik .env, coś jak menedżer haseł. Wklejany do rozmowy klucz zostaje w historii w wielu miejscach naraz.

Test na komputerze: nie pamiętam hasła, zakładam konto na nowy adres — a przy okazji dyktuję: „dorzuć funkcję odzyskiwania hasła, niech się kręci w tle”. Model robi to równolegle, co cieszy. Po rejestracji i onboardingu klikam „pobierz dzisiejszą podpowiedź trenera” — rdzeń całej funkcji. Chcę jednak więcej niż ręczne klikanie, więc dyktuję: „nie chcę, by użytkownik musiał generować podpowiedzi ręcznie; ustal automatyczną kadencję i wypełnij nią aplikację; przy każdym wejściu niech czeka go jakaś forma coachingu; dorzuć powiadomienie push — jak jestem w biegu o piętnastej, niech telefon powie: «Nick, widzę, że ostatnio rozkręcasz X, ale zastanawiałeś się dlaczego? Oto szybki sposób»”.

Pierwsze podsumowanie tygodnia, mimo że danych jak na lekarstwo, brzmi zaskakująco dobrze: „To był trudny tydzień — ogólna realizacja zaledwie 14% w trzech głównych nawykach. Jasnym punktem był piątek, gdy udało ci się wykonać wszystkie trzy w jeden dzień — masz do tego capacity, gdy warczą sprzyjające. Wyzwanie na kolejny tydzień: przenieś tę konsekwencję poza jeden dobry dzień. Spróbuj odtworzyć, dlaczego piątek zadziałał — harmonogram, energia, nastawienie — i świadomie stwórz te warunki na dwa, trzy inne dni”. Brawo. Przy okazji łapię czarną obwódkę wokół górnego paska — kolejkuję poprawkę. Bo tak właśnie pracuję: nie czekam, aż Claude skończy jedno, by zacząć drugie, zwłaszcza niezwiązane — tu funkcje AI, tam design.

Potem poprawiam styl samego trenera. Proszę o dziesięć przykładów podpowiedzi i podsumowań na zasymulowanych danych: „chcę widzieć, co naprawdę zobaczą użytkownicy”. Pierwszy przykład: „Twoja seria medytacji robi wrażenie — 14 dni przy 100% w tym tygodniu. Ale nawodnienie po cichu działa przeciwko tobie: 2 z 7 dni, żadnej serii”. Nie podoba mi się jedno: półpauzy. To typowo „AI-owy” zapis. Dyktuję: „zmień prompt tak, by Claude nie używał półpauz — im ich mniej, tym bardziej ludzko brzmią komunikaty”. Dorzucam: emotikony tylko w tytułach, nigdzie indziej. Generuję trzy próbki — czysto, naturalnie, z tytułami w stylu „solidny tydzień” czy „doskonały tydzień”. Podsumowania są długie, retrospektywne; podpowiedzi — dwuzdaniowe. Dobra proporcja.

Żeby nie klikać w ciemno, każę dodać przyciski deweloperskie: symulacja 30 dni historii i wymuszenie generowania trenera. W Chrome nie zobaczę prawdziwych powiadomień, więc proszę o symulację toastu — krótkiego paska w rodzaju tych od SMS-ów (okno modalne to większy, chwilowy „zasłon”, toast jego zgrabniejszy kuzyn). Koszt sprawdzenia stylu w symulacji jest o rząd wielkości niższy niż przejście całej pętli testów z błędnym komunikatem. Wychodzi pięknie: u góry mały robot-trener, toast zjeżdża w dół, klik przenosi do pełnej treści.

Pora na telefon: „otwórz świeży terminal i uruchom serwer Expo; świeży znaczy w terminalu komputera, nie wewnątrz tego wątku”. Muszę doprecyzowywać, bo model dwa razy odpalał terminal w środku rozmowy. Instaluje się tunel. Na telefonie pojawiają się błędy — ikony znowu obcięte; kolejkuję poprawkę. Przy tunelu wywala się komunikat „nie udało się uruchomić”. Po kilkukrotnym wklejeniu błędu do Claude znajduję przyczynę: serwis tunelujący poprosił o potwierdzenie adresu e-mail, bo uznał mnie za potencjalnego spamera. Weryfikuję i działa. Zostawiam ten fragment w materiale specjalnie: takie drobne tarcia zdarzają się przy programowaniu i większość twórców wycina je z tutoriali, żeby wszystko wyglądało łatwiejsze, niż jest. Nie pytanie, czy traficie na błąd — traficie. Trzymać zimną głowę; rozmawiam w końcu z inteligentnym piaskiem i byłoby nierozsądnie zakładać, że żaden serwer się nie zatnie.

Na telefonie wszystko gra: powiadomienia push (włączone ręcznie w ustawieniach), zamykanie gestem, wyzwalanie na żądanie. Ostatni test stu procent: zaplanowane powiadomienie — każę ustawić jedno na za minutę i wpatruję się w ekran. Pojawiło się. Gotowe.

Audyt bezpieczeństwa

Został ostatni krok przed publikacją, który — moim zdaniem — 99% ludzi w „wibkodowanej” gospodarce pomija, bo jest czasochłonny i nie-seksowny. A to właśnie to jedno procent, którego aplikacje gdzieś dochodzą, zarabiają i mają tysiące użytkowników. Bezpieczeństwo. (Informacja dodatkowa: „vibe coding” — żargonowa nazwa programowania, w którym człowiek steruje modelem językowym promptami, zamiast pisać kod samodzielnie.) Jeśli wasza aplikacja jest wywrotecznikiem bezpieczeństwa, ludzie zaczną jej używać, a gdy ich dane — loginy, hasła — wyciekną w ciemne zakątki internetu, reputację mordujecie w kołysce. Gorzej: otwieracie się na realne odpowiedzialność. Znam przypadki na skalę, gdy ktoś wykradł token API i nabijał rachunki na miliony — a dostawcy refundują takie szkody tylko częściowo, bo ostatecznie to wina właściciela klucza. Do tego regulacje: przy nawykach ryzyko jest umiarkowane, ale przy danych zdrowotnych czy finansowych, zwłaszcza z logowaniem do banków, wyciek może kosztować majątek. Nie jestem prawnikiem ani specjalistą od bezpieczeństwa — jestem facetem, który chce maksymalnego zwrotu z nakładu. A ten uzyskacie w AI prostym sposobem: promptem, który metodycznie odhacza wszystkie niskie wiszące owoce.

Stuprocentowego bezpieczeństwa i tak nie będzie — solo dev albo mały zespół zawsze zostawi dziurę. Chodzi o to, by po przejrzeniu aplikacji ktoś powiedział: „to jest dość dobrze zabezpieczone, nie opłaca się, szukam dalej”. Prompt bierzcie z mojego wcześniejszego kursu (moduł „bezpieczeństwo aplikacji wibkodowanych”). Zanim go wkleicie — aplikacja musi przejść pełną, trzyelementową pętlę testów. Potem /clear, zerowy licznik tokenów, wklejacie wielką ścianę tekstu i puszczacie. Prompt to skomplikowana lista kontroli: fikcyjne pakiety, brak walidacji po stronie serwera, domyślnie otwarte bazy, zaszyte na stałe sekrety, niespójna warstwa autoryzacji. Model wypluwa kilkadziesiąt ustaleń z rangami krytyczną, wysoką, średnią i niską, kategorią, lokalizacją i kodem CWE — katalogu typowych słabości.

Wyniki bywają bolesne: sekretów zaszytych w kodzie brak — zaliczone; pokrycie .gitignore — częściowe; wycieki z konsoli — częściowe; walidacja przy starcie — całkowita porażka; chronione ścieżki API — poważna dziura; drogie operacje, którymi atakujący mógłby w kółko palić moje tokeny — do naprawy. Każę: „napraw wszystko od góry do dołu, a po skończeniu przetestuj, czy w stu procentach rozwiązane”. I tu sedno: nie kończymy na jednym przebiegu. Naprawiając jeden problem, model potrafi stworzyć inny. Czyścisz wątek i odpalasz audyt od nowa — świeżym „oczym” — by wyłapać luki, które zostawiła poprzednia wersja. Specjaliści od bezpieczeństwa kręcą nosami, że należy czytać kod ręcznie; ale cała filozofia AI to mnożenie dźwigni, a ludzie też popełniają błędy — kilka automatycznych przebiegów niewiele ustępuje ręcznemu przeglądowi. Przy aplikacji dla setek tysięcy użytkowników — inna rozmowa, wtedy zespół recenzentów. Po drugim przebiegu jestem zadowolony w 90 procentach: porażki zamieniły się w zaliczenia lub częściowe zaliczenia, rangi spadły do niskich. „Świetna robota — napraw wszystko, także częściowe, i daj znać, czy zmiany nie stworzyły nowych luk”.

Na tym etapie można by jeszcze pójść w TestFlighta — program Apple’a, w którym zespół recenzencki przegląda aplikację w ciągu 24 godzin i pozwala udostępnić ją linkom nawet tysiącom testerów. Nie korzystam — Expo załatwia te 80/20 za darmo.

Standaryzacja procesu: jedna pętla do rządu wszystkiego

Zanim zbudujemy kolejne aplikacje, usystematyzujmy to, co zrobiliśmy. Cały proces to powtarzalny obieg: najpierw koncepcja MVP — „ta jedna rzecz”, pętla działania i nagrody, tylko to, co pętli służy, maksymalnie 5–7 ekranów, haczyk retencyjny. Bez przynajmniej zgrubnego pomysłu przed budową będzie źle. Potem budowa: dyktuję specyfikację, wklejam, Claude robi przynajmniej jeden pełny przebieg — i coś działa. Następnie, nowy krok, którego wcześniej nie eksponowałem: design. Gdy lokalna funkcjonalność jest gotowa, zmiana wyglądu to sama stylizacja — „ten sam układ, inne style, klimat tej aplikacji, w duchu Apple’a czy Google’a” — i model błyskawicznie generuje wersje. Powstała już cała nisza firm, które biorą cudzą funkcjonalność i przepinają design w pięć, dziesięć wariantów dla różnych gustów.

Potem testy — trzy podstopnie: komputer (Chrome), lustrzane odbicie telefonu (szybkie przejrzenie myszką, bez skakania po urządzeniach) i fizyczny telefon (powiadomienia, haptyka — rzeczy nieosiągalne wcześniej; poza tym błędy wyłapane wcześnie nie propagują się w dół). Dalej baza danych z autoryzacją — łatwe, już to widzieliście. I testy od nowa, bo architektura się zmieniła i pojawiły się nowe miejsca awarii. Potem audyt bezpieczeństwa — do tej pory wszystko było lokalne, a po dodaniu bazy i logowania aplikacja de facto żyje w internecie i każdy może się w nią wpiąć. Trzeci przebieg testów. Na końcu wdrożenie — termin ogólny: zgłoszenie do sklepu albo wypchnięcie na produkcyjne repozytorium. Ta sama pętla obowiązuje przy całej aplikacji i przy pojedynczej nowej funkcji. Powtarzasz i powtarzasz.

Aplikacja druga: licznik kalorii w stylu Cal AI

Druga aplikacja bierze całą dotychczasową funkcjonalność — zapis do bazy, odczyt, powiadomienia, AI działające w tle i na pierwszym planie, logowanie, kontakty z API — i pakuje to w szczuplejszą, szybszą, „seksowniejszą” formę: licznik kalorii bardzo podobny do Cal AI. Trochę oszukuję, bo przykład jest znany, ale to świetny sprawdzian AI w klasycznej aplikacji. Zresztą funkcjonalnie nie różni się zbytnio od trackera nawyków: dziennik dzienny, cel kaloryczny ustawiany w onboardingu, dodawanie pozycji w ciągu dnia wypełnia licznik jak cel wyzwania. Jedyny nowy element: zdjęcia jedzenia wysyłane do AI. Zostawiam bazę kodów kreskowych, którą Cal AI dorzuca — rdzeniem pętli jest „sfotografuj jedzenie, otrzymaj szacunek kalorii”. Dokładność jest przyzwoita, ale rozrzucona o 10–15%: model nie wie przecież, jak głębokie jest naczynie. Kaloryczne aplikacje i tak nigdy nie są idealne — będziemy po prostu tak samo dobrzy, jak konkurencja.

Dyktuję specyfikację w pięcioczłonowym schemacie: funkcja rdzenna — śledzenie kalorii na podstawie zdjęcia przetwarzanego przez AI, z powrotem kalorie i makroskładniki, dopisywane do dziennego celu; pętla — trafianie w cele dzienne plus bodziec wizualny przy każdym logowaniu posiłku (użytkownik ma wracać przy każdym posiłku); dodatki — wykresy postępu, kalendarz z historią, czysty interfejs zdjęcia, zgrabna strona główna; powierzchnia — trzy, cztery ekrany: strona główna z rzutem oka na wszystko, ekran zdjęcia, ekran wyniku z korektami (bo AI bywa niedokładne), ekran postępu, ewentualnie ustawienia, jeśli zmieścimy się w limicie; haczyk — powiadomienia „czy zalogowałeś śniadanie/lunch/kolację?” plus gratulacje za serie, więc wbudowujemy serie. Na razie lokalnie, bazę dołożymy później.

Nowy katalog „cal tracker”, ten sam prompt o scaffold — nie pobieramy niczego ręcznie; można by też zduplicować folder trackera nawyków, ale ja minimalizuję tokeny i chcę pokazać, że nowa aplikacja od zera to żaden wysiłek. Po chwili przechodzi test TypeScriptu bez błędów — czyli kod się kompiluje, co nie znaczy jeszcze, że działa. Test w Chrome. Do analizy zdjęć potrzebny klucz API Anthropic — zakładam nowy, nazywam go „Cal Tracker app”, trzymam w .env (model sam upomina się, by nie wklejać klucza w czacie).

Pierwsze uruchomienie: 2000 kalorii do zjedzenia, białko, węglowodany, tłuszcze, dzisiejszy dziennik. Przycisk „zrób zdjęcie lub wybierz z galerii”. Podkładam zdjęcie ryżu z kurczakiem. Błąd: „validate path is not a function” — wklejam, każę naprawić. Ustawienia z przypomnieniami posiłków; kolejny błąd przy zgodzie na powiadomienia — napraw. Poważniejszy: „failed to fetch” — napraw. Idziemy dalej krok po kroku, aż nagle działa: analiza zwraca „udźciegnione udka z kurczaka z ryżem po hiszpańsku, 650 kcal, białko 42, węgle 58, tłuszcz 26” — z możliwością korekty. Dodaję do dziennika, wyskakuje „dodano do logu” z licznikiem pozostałych kalorii. Mamy też serię jednodniową. Kolejkuję kolejne życzenia: edycja wpisów po kliknięciu, porządek w zawijaniu tekstu („przejdź całą aplikację własną pętlą testów i wylicz everything, co poniżej standardu”), prawdziwy kalendarz zamiast słupków, rozjechane nakładające się liczby, edycja historii, klik w dzień kalendarza pokazujący wpisy z tego dnia, naprawa przycisku posiłków w ustawieniach, onboarding z celem (redukcja, utrzymanie, masa, mięśnie), spersonalizowany plan makro i rekomendacja zamiast wymyślania wszystkiego samemu, ewentualnie wzrost i waga do policzenia zapotrzebowania. „Zrób porządny research — nie chcę, żebyś wymyślał z głowy”.

Wdrożenie zajęło 2 minuty 56 sekund — szybciej, niż zrobiłbym to ja. Onboarding pyta o cel, potem liczy zapotrzebowanie wzorem Mifflina–St Jeora. (Informacja dodatkowa: wzór Mifflina–St Jeora to standardowe równanie służące do szacowania dobowego zapotrzebowania kalorycznego.) Płeć, wiek („nie pytajmy o mój wiek… powiedzmy 62”), wzrost i waga — pola rozjeżdżają szerokość ekranu, kolejka do poprawy — poziom aktywności, i mam plan: wydatek energetyczny plus cel kaloryczny, regulowany później w ustawieniach. Rdzeń działa, wpisy klikają się w szczegóły (nazwa, kalorie, makra), ale brakuje zdjęcia — każę dokleić ze kompresją, by oszczędzać pamięć. Kalendarz przewija miesiące i pokazuje zsumowane kalorie; klik w dzień z wpisami otwiera okienko. Ustawienia: trzy przypomnienia — 8:00, 12:30, 18:30 — chcę edytowalne godziny (kto je późne śniadanie), więcej slotów albo dzienny „meldunek wieczorny”. Elastyczność jest ważna, ale nie przesadzajmy z jej ilością. Zasada: być zdeterminowanym — myśleć trochę za użytkownika — ale nie tak, by czuł się uwięziony.

Dorzucam funkcję wstecznego logowania: skoro zapomniałem wczoraj, a jest rano — chcę się cofnąć i dopisać wczorajsze pozycje. Strona główna zyskuje przełącznik dnia (nazwa „pulpit” zamiast „dziś”) i przycisk powrotu do dziś; na stronie postępu klik w dzień otwiera возможность dopisania. Przypomnienia można usuwać i zmieniać nazwy — kto je dwa posiłki, wywala kolację. Test: cofam się do szóstego, loguję to samo zdjęcie — wynik 620 kcal, białko 38, węgle 52, tłuszcz 26. Wobec wczorajszego wyniku niemal identycznie — spójność rozpoznawania robi wrażenie. Edytuję wpis na 650; matematycznie to bez sensu (kalorie znikąd się nie biorą, makra powinny się zmienić), ale daję ludziom kontrolę. Przebiegam onboarding od nowa z celem „utrzymanie wagi” — plan się przelicza, a ważne: stare wpisy zostają, tylko z nowymi wartościami dziennymi. Dokładnie tak ma działać.

Design z inspiracji i z powietrza

Obecny design jest „przyduszony”, a ciemne motywy już mnie nudzą. Podoba mi się klimat Cal AI — nie kopiuję bezlitośnie, zaczynam od wzorca, a potem odbiegam, żeby efekt nie był klonem. Dyktuję: „kocham design tej aplikacji ze zrzutu; zacznij od naśladowania, obecny jest słaby; ma wyglądać niemal identycznie, tylko logo i nazwa — Cal Tracker; potem zmodyfikujemy”.

Bo gdy funkcje stoją, design to głównie style, fonty i kolory — o wiele łatwiejsza robota, a Claude jest w tym wyraźnie dobry. Moje poprawki: nie czysta czerń, tylko ciemnografitowy błękit; fonty szeryfowe do nagłówków (szeryf to ten z „ozdobnikami” na końcach liter — design moda kołysze się między nimi od dekad, ale szeryf nada aplikacji charakter); emotikony monochromatyczne, w tonacji palety; krawędzie mniej zaokrąglone dla wrażenia „premium” (aplikacje są okrągłe, bo telefony są okrągłe — ale my chcemy dystynkcji); paleta zimnego błękitu. Kolory biorę z aplikacji uicolors — przestawiam próbnik na ciemny, chłodny błękit, kopiuję skalę i wklejam: „zaktualizuj schemat kolorów tak, by wyglądał jak to; wszystkie ikony i emotikony monochromatyczne; trzymamy się tej palety od teraz; fonty szeryfowe w nagłówkach; zmniejsz zaokrąglenia o włos”.

Pierwsze wyniki wciąż kulą — projektowanie to pętla. Zrzuty, poprawki, zrzuty. Nagłówek „udźciegnione udko z ryżem” ucięty na hoverze — każę skrócić tytuły generowane przez AI i łamać tekst zamiast go ucinać, „a łamanie ma wyglądać dobrze”. Na stronie profilu rozjechały się karty — model zmienił kolory, nie przejrzał wszystkich ekranów. Dyktuję harmonizację: „usuń obwódki wokół wszystkich kart, prostota ponad zatłoczenie; rozłóż elementy na stronie głównej organicznie zamiast stawiać w słup; zamiast szeryfów weź sprawdzony bezszeryfowy font kojarzony z wysoką półką; przejdź każdą stronę zrzutem i wylicz usterki przed poprawką; zielony przycisk przy przypomnieniach nie pasuje do palety — zmień”. Potem: „przejdź design strona po stronie, wylicz i policz wszystkie możliwe ulepszenia ku wyższej półce, zapętlaj się sam tyle razy, ile trzeba — wciąż jest ciasno i szaro; ikony dolnych zakładek wyglądają tanio — wymień; dorzuć wykres dziennej wagi jak w Cal AI”.

Po kilku obiegach robi się naprawdę ładnie: profil w ciemnym błękitnie, monochromatyczne karty, czysta strona postępu z łatwym usuwaniem wpisów i sensownym edytorem makro. Strona główna dalej „upakowana” — ale to wszystko kwestia kilku promptów. Dodaję logowanie wagi pod przyciskiem plus: wykres liniowy masy w czasie. Ważna obserwacja: skoro wszystko jest lokalne, zmiany strukturalne są tanie; przy żywej bazie każda zmiana pushowałaby nowy schemat do Supabase, deprecjonowała stare dane i wydłużała testy. Dlatego design dopinam przed bazą.

Strona główna wciąż nie działa — model „przepycha” elementy do środka, coś fundamentalnie źle rozumie. Każę otworzyć własne okno Chrome, przejść aplikację zrzutami i wyliczyć drobne niekonsekwencje — odstępy, marginesy, wyrównanie — a potem poprawić każdą. Dorzucam: „kółka z białkiem, węglami i tłuszczem powiększ, żeby zniknęły dziwne odstępy; mają być proporcjonalne do szerokości strony”. W międzyczasie równolegle przechodzę swój onboarding w drugim oknie. Logowanie wagi wyskakuje poza ekran — stała szerokość — poprawka w kolejce. Po dwóch pomiarach (175, 176) pojawia się trend; do tego data pomiaru edytowalna, a lista „ostatnio zalogowane” obejmuje i posiłki, i wagę, bo logowanie masy nie może być zakopane na stronie postępu. Na małych ekranach karta z długim tytułem rozciąga się na cztery linie — każę zmieścić wszystko w dwóch, tytuł i dane kaloryczne, „skróty, mniejszy font, co trzeba — byle widoczne było dwa razy więcej znaków”. Zanim wydam polecenie, zawsze upewniam się, że wiem, czego chcę — płacę tokenami za każde niedopowiedzenie. Wpis „poranny bieg” z jednostkami wyrównany; wykres wagi dostaje oś z datami; oś w szeryfie — poprawka na bezszeryfowy. Zielony przełącznik przypomnień — na błękit. I to jest koniec designu trzech stron.

Test na telefonie (poza kadrem) — i jest czysto: haptyka i interakcje działają, układ „absolutnie piękny”. Drobiazgi wyrównania wyszły dopiero na sprzęcie. Kamery nie pokażę przez aplikację lustrzaną (się wywala), ale jej przepływ jest identyczny jak w Chrome. Zbudować coś takiego w 15–20 minut — przyjemność.

Baza, kompakcja, optymalizacja i audyt dla licznika

Kolejny krok: baza. Ale najpierw higiena: licznik tokenów urósł, a po przekroczeniu około 200 tysięcy jakość drobnych poprawek spada — moja reguła: przy 250–300 tysięcy robię /compact, które spina całą historię rozmowy w skondensowane streszczenie. Z „naprawiono: aplikacja teraz jawnie prosi o uprawnienia do kamery i biblioteki zdjęć” robi się „naprawiono: prośba o uprawnienia przed uruchomieniem wyboru zdjęć” — ta sama treść w połowie długości, a odzyskane tokeny poprawiają jakość kolejnych iteracji. Minus: trwa. W tym czasie zakładam projekt „Cal Tracker” w Supabase — i koniecznie zaznaczam automatyczny RLS. Ta opcja kiedyś nie istniała; doszła dlatego, że tyle „wibkodowanych” aplikacji przeciekało, że Supabase postanowiło domyślnie chronić. Szczerze? Powinno być obowiązkowe, z rezygnacją na wyraźne życzenie.

Po integracji: wylogowanie prowadzi do strony logowania — zaprojektowanej tak, że wgrałem do Claude podoba mi się ekran z Dribbble i poprosiłem o podobny; wyszło z uroczymi, małymi „kaloriami i wagami” skaczącymi w tle. Logowanie wrzuca prosto do aplikacji. Poprawiam drobiazgi: migotanie onboardingu, opóźnione przełączniki (baza odpowiada sekcję za długo — każę cacheować). Potem puszczam autonomiczną pętlę: „otwórz każdą stronę aplikacji i wylicz drobne ulepszenia użyteczności oraz szybkości ładowania”. To meta-system, w którym AI robi i koncepcję, i wdrożenie — ja tylko zerkam na wynik. Dorzuca style kart, „zapisz jako ulubione” — funkcje dodatkowe; chcę parytetu z Cal AI przed zgłoszeniem. Wszystko to jest pochodną zużycia tokenów: 24 tysiące w niecałe sześć minut pracy w tle. Jeśli stać was na taki budżet, wymieniacie pieniądze na tokeny, a tokeny na czas.

Na telefonie logowanie pozycji trwało 700 ms–1 s — irytujące. Zasada: na telefonie wszystko czuje się dwukrotnie gorzej niż na komputerze. Pytam, co ładuje się najdłużej, i każę zoptymalizować: pojedyncze zapytanie do bazy zamiast serii oszczędza około 600 ms w sieci komórkowej, pełne przeładowanie strony głównej schodzi ze średnio 254 ms na 219 ms — cała aplikacja dostaje kilkanaście procent zwrotu, a opóźnienie sieciowe z około pół sekundy spada do ~80 ms. Tyle że dotknąłem sedna przy okazji testów na telefonie — więc od nowa: komputer, lustrzane odbicie, telefon. Męczące, ale nie ma innej drogi do pewności; nie chcę żadnego zespołu QA, robię wszystko sam z Claude.

Jedna rzecz wyszła dopiero na telefonie: pasek systemowy — zegar, bateria, zasięg — był biały i znikał na ciemnym tle. Pytam, jak wymusić kolory; naprawione. Nie ma testu kończącego się przed pełnym obiegiem. Potem audyt bezpieczeństwa tym samym promptem co poprzednio: /clear, wklej, analizuj, napraw, wyczyść, powtórz. I trójstopniowa pętla testów. Gotowe.

Aplikacja trzecia: pomodoro z rosnącym lasem

Trzecia aplikacja zmiesza tracker nawyków z czasomierzem: pomodoro. Dla nieznających: pomodoro to blok 20–25 minut nieprzerwanej pracy, potem pięć minut przerwy; z tygodnia na tydzień wydłużasz bloki i trenujesz koncentrację. Trackery to mój wybór dydaktyczny — pokazują całą mechanikę „pod maską” najtaniej — ale ten sam proces przeniesiecie na dowolny pomysł.

Przechodzę framework od lewej do prawej, odhaczając. Funkcja rdzenna: licznik z regulowanym czasem (15/25/45/60 minut). Pętla: aplikacja jest tak prosta, że potrzebuje wyjątkowego wizualnego magnesu — uruchamiasz sesję, sadzisz nasionko i patrzysz, jak przez 25 minut rośnie drzewo; na koniec wibracja i dźwięk. Telefon leży na biurku, a na ekranie powoli żyje coś, o co trzeba dbać. Dodatki: log sesji i postępów, zmiana gatunków drzew, poziomy i kolory. Powierzchnia: dwa ekrany — „uprawa” i „las”. Haczyk: codzienny meldunek; jeśli nie wrócisz w ciągu 72 godzin, drzewka więdną. Każda sesja to jedno drzewo; z czasem wyrasta las.

Scaffold jak zwykle, potem dyktuję całość. Tym razem Claude pracuje inaczej: uruchamia podagenty — obok głównego wątku drugi agent przeszukuje biblioteki animacji React Native — a potem wchodzi w tryb planowania i zadaje pytania: drzewo ma rosnąć w czasie rzeczywistym (w połowie czasu — pół drzewa) czy jako gotowa animacja na końcu? Odpowiedź: w czasie rzeczywistym. Trwałość danych: lokalna baza SQLite. Domyślna sesja: 25 minut, regulowana. Model zwykle sam rekomenduje opcje — i znowu trafił w moje intencje; pyta teraz, by nie płacić później tokenami za przebudowę.

Pierwsza wersja rozwija SVG — nie mam wielkich nadziei co do urody, ale onboarding („zasadź nasionko… wyhodujesz drzewo… zdobądiesz punkty doświadczenia i nowe gatunki… pielęgnuj las”) jest uroczy. Struktura idealna: strona uprawy i strona lasu z sesjami, godzinami, serią, poziomem, odblokowanym dębem i recent sessions. Każę wpompować dane do bazy, żeby zobaczyć aplikację zaludnioną — bez tego nie oceni się designu. Odhaczam „build”. Przychodzi czas na poprawki: przyciski 15/25/45/60 nie są responsywne; u góry ogromna pustka, dopóki drzewo nie urośnie — brzydko i dziwnie; nie chcę przewijać; las obcina korony drzew; strona główna ma być wizualnie żywsza — dziś są tylko znacznik poziomu, płomyk serii i czas. Chcę też: dużo ładniejsze drzewa (dziś to kółka), klikalne sesje, wykres pod lasem, wyraźniejsze oznaczenie więdnących (komunikat mówi o dwóch, widzę trzy — możliwy błąd w danych), interakcje — stuknięcie ma coś wywoływać — animacje (statyczne drzewo jest urocze, ale nie wystarczy) oraz tryb deweloperski do wyzwalania wszystkich stanów animacji.

Większa zmiana designu wymaga wzorca. Przeglądam Dribbble: ciepła paleta jakiejś aplikacji do snu, wykresy, makiety trackerów czasu — jeden pomodoro-tracker jest przeciążony, inny ma „historię i trwające projekty”. Chcę czegoś radosnego, młodzieżowego, niemal dziecięcego. I wtedy pomysł: niech AI obrazowe samo wygeneruje design. Dyktuję do Claude (funkcją bocznych pytań, by nie przerywać pracy): „opisz tę aplikację jako prompt do generatora obrazów, żeby stworzył przemyślany zestaw makiet”. GPT Image — jeden z lepszych generatorów — umie robić całe makiety mobilne. Rezultat wychodzi o klasy lepiej: cudne tekstury, pole, mechanika wzrostu w tle, las z informacjami. Struktura naśladuje naszą aplikację — czyli brakowało nam wyłącznie assetów. Każę odzyskać z makiet drzewa i tła jako osobne obrazy; część widać w siatce, więc proszę: „potnij, przytnij i podziel obrazy, zanim ruszysz dalej — chcę prostą listę zasobów”. Wrzucam je do folderu images i dyktuję: „myśl mocno, krojąc — musi być idealnie; potem zapętlaj się w nieskończoność, aż design będzie niemal piksel w piksel”. Grafika generatywna ma swoje kaprysy: tła w akwarelowym stylu trudno odtworzyć proceduralnie, drzewka w jednym obrazie bywają różne (w aplikacji będą identyczne) — część rzeczy pomijam (np. przyciski), resztę da się zrobić.

Efekt? Onboarding wygląda dokładnie tak, jak chciałem — organiczny, wrośnięty w aplikację, responsywnie rosnący, bez dziwnych linii. Górne narożniki obrazów są jeszcze „kwadratowe”; każę gradient wpuścić głębiej tylko u góry, aż dojdzie wrażenie zaokrąglonej arkady — „a to jest przepiękne; dorzucę jeszcze 10% intensywności”. Reszta aplikacji jeszcze nie dorównuje onboardingowi — dyktuję: „rozprowadź wygenerowane assety po całej aplikacji od góry do dołu, rób zrzuty i zapętlaj się; onboarding zostaw, zajmij się uprawą i lasem — mają wyglądać jak obrazy z folderu”. Wychodzi: nasionko, tapnięcie w czas zmienia długość sesji, guzik startu. Dorzucam dwie rzeczy: stuknięcie w nasionko (i każde drzewo na stronie uprawy) daje lekką wibrację i „trzęsienie”, jakby było żywe; a licznik ma wisieć nad drzewem, nie pod nim — skoro dół ekranu jest „ziemią”, zegar na dole nie ma sensu. Drzewa bywają różne — iglaki, kwitnące; klik pokazuje gatunek i „zdrowie”; więdnące da się ratować, wracając do sesji. Po drodze drobiazgi: licznik przysłania pęd — wyżej; może więcej jasności wokół poziomów. Sadzę nasionko na kilka minut i mam pierwszy kiełek w lesie.

Po zbudowaniu i wytestowaniu (Chrome, lustrzane odbicie, telefon — znowu trochę zbyt dużo back-and-forth) dołączam bazę: projekt „Pomodoro app” w Supabase, wygenerowane hasło, automatyczny RLS, wklejam klucze. Powstają trzy tabele: sesje, drzewa i statystyki użytkownika. Wyłączam potwierdzanie e-maila i testuję całość. „Witaj z powrotem, twój las czeka” — urocze, choć nasionko wymaga wymiany; na to właśnie są testy. Przy okazji wyszło, że część ikon nie daje się uratować — generator skleił je w siatce i AI źle je potnęło. Rozwiązanie: każę ChatGPT wygenerować każdy element osobno, z usuniętym tłem — kosztuje 10–20 centów, a oszczędza wieki. Obiecujący kierunek: AI generuje grafikę bez tła, a potem takimi „sprite’ami” animuje się wzrost.

Publikacja w App Store

Trzykrotnie przeszedłem cały proces — czas opublikować. Wybieram najbardziej złożoną aplikację, licznik kalorii, ale dokładnie te same kroki zastosujecie do pomodoro, trackera nawyków czy czegokolwiek. Przygotowałem pełny przewodnik w dokumencie: od gotowej aplikacji Expo do zgłoszenia w sklepie. Od razu uprzedzam: nie ma gwarancji przyjęcia. Apple ma rygorystyczne zasady i zobaczycie całą biurokrację, którą trzeba przejść — zrzuty w idealnym rozmiarze, polityki prywatności, formularze. To część gry. Wszystkie te kroki można (i warto) przepchnąć przez Claude czy inny agent — przewodnik zawiera gotowe prompty.

Najpierw przygotowanie do produkcji. Potrzebne pliki: app.json (nazwa, identyfikator, wersja, ikona — wszystko, czym Apple identyfikuje aplikację) i eas.json dla Expo; do tego ikona 1024×1024, ekran startowy i — pod Androida — ikona adaptacyjna, czyli pierwszy plan na kolorowym tle. Brzmi strasznie? Claude robi to za was — wystarczy poprosić o konfigurację; on uzupełnia opisy, uprawnienia (nasza aplikacja używa dźwięku przy kamerze) i wersje.

Potem build produkcyjny. Aplikacja ma kilka stanów: wersja testowa pod Expo to żywy organizm, który ciągle edytujesz; wersja sklepowa to skrystalizowana paczka — parametry ustawione na sztywno, przez co działa szybciej. W terminalu loguję się do EAS — to system Expo, który automatyzuje budowanie i zgłaszanie; kiedyś publikacja była jeszcze większym bólem, zanim Expo powstało. W darmowym planie kolejka bywa długa — trudno. Równolegle zakładacie konta: Apple Developer (developer.apple.com/account) i Google Play Console (play.google.com/console/signup). Procedury się zmieniają, więc nie będzę ich szczegółowo przepisywał, ale kilka rad: dla Google używajcie firmowego adresu (Workspace za kilka dolarów miesięcznie) — weryfikacja przebiega wtedy dużo szybciej, a i tak zakładacie biznes; mój to nick@leftclick.ai, moja agencja. Google wymaga też udowodnienia dostępu do fizycznego urządzenia z Androidem — chcą, żeby aplikacja była realnie testowana.

Najbardziej żmudny etap to prywatność i zgodność: platformy wymagają publicznie dostępnej strony z polityką prywatności i wsparcia. Moja stoi na leftclick.ai — całą stronę wygenerowało Claude po wklejeniu wytycznych Apple: „tworzę aplikację Cal Tracker, przygotuj politykę prywatności i wystaw na mojej stronie”. Wyszło z sekcją kontaktu, FAQ o dokładności szacunków AI i instrukcją konfiguracji klucza API. Dosłownie dwa pytania i gotowe — nie ułożyłem ani jednego zdania ręcznie. Strona powinna być pod domeną, najlepiej tą samą co wasz e-mail.

Samo zgłoszenie: po zbudowaniu paczki w EAS uruchamiam eas submit dla iOS, loguję się do konta Apple (klucz na komputerze robi to automatycznie), wybieram właściwy build z listy i po kilku minutach Expo prowadzi mnie na stronę zgłoszenia. Formularz trzeba przejść od góry do dołu: zrzuty ekranu dla iPhone’a 6,5 cala i iPada (Claude potrafi je teraz robić sam, otwierając przeglądarkę), tekst promocyjny, opis i słowa kluczowe — wszystko skopiowane od Claude; URL wsparcia i marketingowy, wersja 1.0, prawa autorskie, wybór buildu. Ciekawostka: wymagane dane logowania dla recenzenta — konto testowe, którym człowiek z Apple zaloguje się do aplikacji i sprawdzi jej działanie. Zaznaczam „automatycznie wydaj tę wersję”. Dalej: informacje o aplikacji, kategorie, oceny wiekowe, prawa do treści, recenzje, prywatność (tu wklejamy politykę; pola opcjonalne pomijam), cennik — ustawiłem darmową — ewentualne zakupy w aplikacji, oświadczenie, że to nie hazard. I w prawym górnym rogu: „wyślij do recenzji”. Wysłane.

Gwarancji brak — ale wypełnienie wszystkich stron znacząco podnosi szanse, a recenzenci zwykle piszą, co poprawić. Przed publikacją sensowny jest TestFlight: link dla kilku bliskich testerów, którzy realnie poszukają usterek, zanim aplikacja trafi do wszystkich. W tym materiale nie mogłem robić dwutygodniowego testowania — stąd sam opis. Po premierze zostaje analityka i optymalizacja karty produktu: strony promocyjne, kody zniżkowe, eksperymenty.

Na koniec

Dziękuję za przejście całej drogi — uwielbiam robić takie kompleksowe kursy. Jeśli wam zasmakowało, mam obszerny, czterogodzinny kurs Claude Code od podstaw: ikony, przyciski, zarządzanie kontekstem, głębokie inżynierie promptów — tutaj poznaliście podejście „od góry”, tam dostaniecie budowę „od dołu”. Są też kursy zaawansowane: optymalizacja umiejętności pod pracę wiedzową, orkiestracja wielu podagentów. A gdy już umiecie budować, naturalne pytanie brzmi: co z tym zrobić? Wielu ludzi monetyzuje te umiejętności jako usługę — w mojej społeczności Maker School (z 90-dniową gwarancją zwrotu, jeśli nie zdobędziecie pierwszego klienta) ponad dwa tysiące osób uczy się sprzedawać takie technologie: zimne e-maile, sekwencje wiadomości, marki w mediach społecznościowych, lejki pozyskujące klientów bez polecek. Kto dotrwał do końca czterogodzinnego kursu, ten przeboleje dwie minuty reklamy. Pomysły na kolejne materiały zostawcie w komentarzach — chętnie czytam. Do zobaczenia. I proszę, zasubskrybujcie kanał — nie lubię prosić, ale to realnie pomaga.