O czym jest ten film
- Piąty miesiąc pracy nad Amy — aplikacją do liczenia kalorii w stylu Apple Notes; kluczową metryką autora jest retencja po pierwszym tygodniu, obecnie 13%.
- Niewygodne wyznanie: w zeszłym miesiącu autor błędnie policzył wskaźnik (podał 20%, faktycznie było ok. 14%), więc zamiast skoku nastąpił spadek.
- Finanse: ok. 2800 dolarów MRR, 3000 dolarów przychodu w 30 dni, koszty ok. 400 dolarów (głównie wywołania AI), marża rzędu 85%.
- Strategia na retencję: maksymalne ograniczanie tarcia — poprawki błędów, dokładność AI i dwie nowe funkcje.
- Skanowanie kodów kreskowych: research przez Claude Deep Research przed pisaniem kodu, rozbicie zadania na dwa problemy i porównanie baz Open Food Facts i FatSecret.
- Ostateczne rozwiązanie: odpytywanie obu baz równolegle i wybór lepszego wyniku bardzo tanim modelem Gemini 2.5 Flash-Lite.
- Przypadki brzegowe wykryte dopiero w codziennym użyciu: edycja porcji, awaryjne zdjęcie etykiety żywieniowej zamiast kodu, etykieta oplatająca całą butelkę.
- Śledzenie wody — funkcja zbudowana dla samego autora; rozpoznawanie wpisów oparte na lekkim LLM zamiast słów kluczowych, żeby działało w każdym języku.
- Filozofia prostoty: nowe funkcje całkowicie opcjonalne i domyślnie wyłączone, żeby nie przeładować interfejsu.
- Mniej efektowne, ale prawdopodobnie najważniejsze dla retencji: dokładność wyliczeń i żmignie usuwanie drobnych usterek; efekt zobaczymy dopiero za kilka tygodni. Plus segment sponsorowany WhisperFlow.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Retencję buduje się usuwaniem tarcia, a nie dokładaniem funkcji
Na czym polega: Najskuteczniejsza droga do tego, by ludzie wracali, to aplikacja tak wygodna, że korzystanie samo zamienia się w nawyk. Autor skupił się na poprawkach błędów, trafności AI i nowych metodach wpisywania posiłków, które skracają drogę od myśli do zapisu.
Jak stosować: Przejdź krytycznie każdy krok nowego użytkownika i przy każdym pytaj, co można pominąć. Nową funkcję dokładaj tylko wtedy, gdy realnie skraca zapis — jak zdjęcie posiłku zamiast ręcznego wpisywania.
Na co uważać: Funkcja dodana „bo ma ją konkurencja” może paradoksalnie wydłużyć ścieżkę i dodać punktów zacięcia zamiast je zabrać.
2.Zanim napiszesz kod, zleć research dostępnych API
Na czym polega: Nie wiedząc, jak zbudować skaner kodów, autor najpierw poprosił tryb Deep Research w Claude o wskazanie dostępnych usług — i dopiero potem siadł do kodu.
Jak stosować: Przy każdej funkcji zależnej od usług zewnętrznych zacznij od zapytania w trybie głębokiego researchu: opisz kontekst, poproś o porównanie opcji wraz z cenami i ograniczeniami. Dopiero potem projektuj.
Na co uważać: Raport maszyny to punkt wyjścia, nie wyrocznia — kluczowe pułapki (np. darmowy plan działający tylko na jednym rynku) wychodzą dopiero w testach na własnych danych.
3.Rozbij funkcję na podproblemy — ich trudność bywa bardzo różna
Na czym polega: Skanowanie kodów okazało się dwoma odrębnymi zadaniami: odczyt identyfikatora ze zdjęcia (trywialny dzięki VisionKit) i zamiana identyfikatora na konkretny produkt (trudny, bo zależy od jakości bazy danych).
Jak stosować: Przed implementacją wypisz etapy funkcji i osobno oszacuj ryzyko każdego. Proste elementy z powodzeniem zleisz narzędziom AI od razu; czas rezerwuj na te trudniejsze.
Na co uważać: Szacunek „dzień pracy” łatwo się rozsypuje — to, co wygląda na jedno zadanie, po rozbiciu często okazuje się kilkudniową walką z przypadkami brzegowymi.
4.Gdy żadne API nie wygrywa, użyj dwóch i dodaj taniego arbitra
Na czym polega: Open Food Facts miał lepszą bazę międzynarodową, FatSecret lepsze porcje produktów amerykańskich. Autor odpytuje więc obie bazy naraz, a bardzo tani model Gemini 2.5 Flash-Lite wybiera z dwóch wyników lepszy.
Jak stosować: Zaprojektuj przebieg z równoległymi zapytaniami do dostawców i jedną lekką decyzją modelu. Koszt pojedynczego taniego wywołania bywa pomijalny wobec zysku jakości dla użytkownika.
Na co uważać: Każde dodatkowe wywołanie podnosi koszty i czas odpowiedzi — pilnuj marży i limitych, a w interfejsie przewidź wyjście awaryjne na wypadek, gdy obie bazy zawiodą.
5.Testuj produktem w prawdziwym życiu, nie losowymi próbkami
Na czym polega: Wszystkie poważne problemy skanera — podarte kody, nietypowe porcje, etykieta na butelce — wyszły dopiero, gdy autor używał aplikacji przy własnych zakupach. Testy na „czystych” produktach niczego z tego nie wykazały.
Jak stosować: Przed premierą funkcji przez kilka dni korzystaj z niej jak zwykły użytkownik: prawdziwe zakupy, zabrudzone opakowania, nietypowe sytuacje. Każde potknięcie zapisz jako przypadek testowy na przyszłość.
Na co uważać: Drobiazgi zbagatelizowane na etapie testów u użytkowników podważają zaufanie do całej funkcji — a utraconego zaufania nie odzyskuje się promocją.
6.Dla każdej metody wpisu zaplanuj drogę awaryjną
Na czym polega: Gdy kodu kreskowego nie ma albo skan nic nie zwraca, aplikacja pozwala sfotografować etykietę z wartościami odżywczymi, a AI odczytuje z niej kalorie i makroskładniki — rozwiązanie, którego autor nie spotkał u konkurencji.
Jak stosować: Dla każdej drogi wejścia (kod, zdjęcie, tekst) zaprojektuj plan B: co użytkownik może zrobić w pięć sekund, gdy pierwsza zawiedzie. Logika autora jest uniwersalna — skoro ktoś trzyma opakowanie, ma przy nim także etykietę.
Na co uważać: Awaryjna ścieżka generuje własne przypadki brzegowe (np. etykietę oplatającą butelkę) — licz na iteracje, np. doklejanie wielu zdjęć w jedną całość.
7.Przy użytkownikach z całego świata unikaj słów kluczowych — użyj lekkiego LLM
Na czym polega: Proponowane przez narzędzie rozpoznawanie wpisów po słowach („water”, „H2O”, „oz”) padłoby przy tekście w innym języku. Zamiast tego tani model klasyfikuje wpis — woda, jedzenie czy jedno i drugie — niezależnie od języka.
Jak stosować: Tam, gdzie trzeba rozpoznać intencję w tekście dowolnego języka, wstaw tanie zapytanie klasyfikujące przed głównym potokiem przetwarzania, a kategorie o innej logice (tu: woda) kieruj osobną ścieżką.
Na co uważać: Każdy wpis uruchamia teraz więcej wywołań modeli. Pilnuj kosztów (u autora detekcja wody działa tylko u osób z włączoną funkcją) i przetestuj stabilność, zanim wdrożysz.
8.Nowe funkcje rób opcjonalne i domyślnie wyłączone
Na czym polega: Śledzenie wody można wyłączyć przy rejestracji; gdy jest wyłączone, nie zostawia żadnego śladu w interfejsie, a backend nawet nie próbuje go przetwarzać. Prostota UI i oszczędność w jednym.
Jak stosować: Gdy chcesz sprawdzić pomysł (u autora: cukier, kofeina, alkohol), dodaj go jako przełącznik domyślnie wyłączony. Główny ekran nie puchnie, a od razu widzisz, kto naprawdę chce z funkcji korzystać.
Na co uważać: Funkcja ukryta domyślnie potrzebuje czytelnego momentu odkrycia — w rejestracji lub ustawieniach. W przeciwnym razie nikt nie dowie się, że istnieje.
9.Buduj też dla siebie — to najlepsze paliwo przy wypaleniu
Na czym polega: Śledzenie wody powstało, bo autor sam zapominał pić podczas podróży. Po żmudnym projekcie skanera to właśnie „zabawa dla siebie” odnowiła mu energię — i wyszła z najwięcej dbałością o detal (animacje, ilustracje).
Jak stosować: Żmudne, ważne prace przeplataj małą funkcją rozwiązującą twój własny problem. Motywacja przychodzi sama, a własnych potrzeb słuchasz uważniej niż zgłoszeń.
Na co uważać: Własny problem nie zawsze jest problemem rynku — mierz użycie po premierze. I pilnuj spójności wizualnej: koncept „butelki z kaczuszką” wyglądał u autora jak osobna aplikacja, więc został mocno stonowany.
10.Dokładność i drobne usterki decydują o zaufaniu bardziej niż nowe funkcje
Na czym polega: Zły wynik przy „burrito z kurczakiem” odbiera użytkownikowi zaufanie natychmiast, a suma małych irytacji (np. rozjeżdżające się kolumny przy przewijaniu) systematycznie wypycha ludzi z aplikacji. To najmniej efektowne, ale najważniejsze prace nad retencją.
Jak stosować: Zrób przegląd najczęstszych zapytań użytkowników i porównaj wyniki z etykietami. Prowadź listę zgłoszonych drobiazgów — także tych trudnych do odtworzenia — i zamykaj je planowo, po kilka na cykl.
Na co uważać: Efekt tych prac nie pokaże się od razu. Retencję oceniaj po pełnych tygodniach i kohortach, a nie na podstawie pojedynczych dni.
Redakcyjne tłumaczenie
Piąty miesiąc Amy i wyznanie, które boli
Pięć miesięcy temu wypuściłem Amy, aplikację do liczenia kalorii, i przez większość tego czasu najważniejsza dla mnie metryka — retencja po pierwszym tygodniu — powoli pięła się w górę. Wyjaśnijmy od razu, o co chodzi: ten wskaźnik pokazuje, ile osób po rejestracji nadal korzysta z aplikacji siedem dni później. Dziś stoimy na 13%, czyli ze stu nowych użytkowników trzynastu zostaje dłużej niż tydzień. Liczba jest kluczowa, bo wprost odpowiada na pytanie, czy aplikacja realnie daje ludziom wartość.
I teraz coś, do czego przyznania jest mi po prostu wstyd. W poprzednim odcinku serii euforycznie relacjonowałem, że retencja skoczyła z 12% na 20%, i poświęciłem temu cały film. Tymczasem policzyłem wtedy wynik źle: nie było 20%, było około 14%. A w tym miesiącu spadło do 13%. Zamiast rosnąć — cofamy się. Chciałem to nadrobić, więc przez ostatnie tygodnie miałem jeden cel: podbić tę liczbę tak wysoko, jak się da. Wdrożyłem dwie duże funkcje i przy okazji nazbierałem mnóstwo lekcji, którymi warto się podzielić.
Jeśli trafiliście tu pierwszy raz — witam. Jestem Chris i buduję aplikacje zwiększające produktywność; zwykle każdy film poświęcam jednej z nich, dziś jest to Amy. Dla przypomnienia: to licznik kalorii stylizowany na Apple Notes. Po lewej wpisujecie, co zjedliście, po prawej jak za dotknięciem różdżki pojawiają się kalorie. Z założenia ma to być najwygodniejszy sposób śledzenia diety na rynku.
Skrót finansowy: 2800 dolarów MRR i 85% marży
Zanim przejdę do działań na retencji, szybko przebiegnę po pozostałych liczbach, bo wiem, że je lubicie. Miesięczny przychód powtarzalny (MRR) wynosi około 2800 dolarów, a przez ostatnie trzydzieści dni aplikacja zarobiła w sumie blisko 3000 dolarów. Koszty to jakieś 400 dolarów — w przeważającej mierze, jak łatwo zgadnąć, wywołania modeli AI. Daje to bardzo zdrową marżę w okolicach 85%. Dobra wiadomość: przy poprzednim podsumowaniu dopiero przekraczaliśmy próg 2000 dolarów MRR, więc tu trend jest wyraźnie wzrostowy. No i zostaje retencja: 13%.
Recepta na retencję: zabierać tarcie, a nie dokładanie funkcji
Najskuteczniejszy sposób na poprawę retencji tygodniowej to ograniczanie tarcia — usuwanie wszystkiego, co użytkownika spowalnia. Aplikacja ma być tak wygodna, że korzystanie z niej samo zamienia się w nawyk. U mnie oznaczało to górnę poprawek błędów, pracę nad trafnością AI oraz dwie spore nowości.
Amy od początku szło w tę stronę. Na start było to w gruncie rzeczy Apple Notes z liczeniem kalorii. Potem, pod wpływem lawiny uwag użytkowników, doszło wpisywanie ze zdjęć — długo się przed tym broniłem, a dziś to jedna z najchętniej używanych funkcji, która realnie ułatwia zapis posiłku. Następnie skanowanie menu: robicie zdjęcie karty dań, a aplikacja wyciąga z niej konkretne pozycje. Nie spotkałem się z tym w żadnym innym liczniku kalorii i jestem z tego pomysłu szczerze dumny.
Kolejna metoda wpisów, o którą użytkownicy prosili najgłośniej — ponad stu zwolenników na tablicy propozycji — to skanowanie kodów kreskowych. Standard w tej branży: przykładacie telefon do paczki chipsów, skanujecie kod, a kalorie liczą się same.
Skaner kodów: research przed pierwszą linią kodu
Powiem szczerze: pierwsza moja myśl brzmiała „jak to w ogóle ugryźć? Czy w ogóle istnieje jakieś API?”. Rzeczywiście nie wiedziałem, od czego zacząć. Dlatego, zanim napisałem pierwszą linijkę, zrobiłem to, co robię zawsze, gdy nie znam dostępnych usług: sięgnąłem po tryb Deep Research w Claude. (Informacja dodatkowa: Deep Research pozwala modelowi samodzielnie przejrzeć setki źródeł i złożyć z nich raport z rekomendacjami.) Opisałem sytuację i zapytałem wprost, czego użyć do obsługi skanowania kodów. Robię to regularnie, bo ostatniego, czego chcę, to zbudować pół funkcji i dopiero wtedy odkryć, że istniała lepsza usługa.
Claude przejrzał setki stron, znalazł sporo sensownych API i zwrócił mi krótką listę kandydatów. I wtedy uświadomiłem sobie, że skanowanie kodów to w istocie dwa osobne zadania. Pierwsze: odczytanie kodu, czyli wyciągnięcie identyfikatora produktu ze zdjęcia. Drugie: odnalezienie produktu przypisanego do tego identyfikatora — zamiana numeru na konkretną paczkę chipsów.
To pierwsze okazało się banalne. VisionKit od Apple ma tę funkcjonalność gotową, implementowano ją niezliczone razy, więc Claude Code załatwił sprawę za jednym podejściem. To drugie — dopasowanie identyfikatora do produktu — sprawiło znacznie więcej kłopotu.
Test baz danych: remis zamiast zwycięzcy
Pierwszy dostawca, którego spróbowałem, to Open Food Facts. Fajny projekt: darmowa, kuratorowana przez wolontariuszy baza około czterech milionów produktów ze 150 krajów — ta międzynarodowość okaże się później kluczowa. Podpiąłem ją błyskawicznie i na próbę zeskanowałem opakowanie odżywki białkowej. Trafienie za pierwszym razem, do tego dostałem zdjęcie produktu, którego zupełnie się nie spodziewałem. Był jednak zgrzyt: domyślna gramatura uparcie ustawiała się na 100 gramów, podczas gdy porcja według etykiety to dwie miarki, czyli 35 gramów. Nie chcę zmuszać nikogo, by przeliczał porcje w pamięci.
Poszedłem więc po drugiego dostawcę — FatSecret. Mają darmowy plan, a w tym samym teście wypadli wzorowo: poprawny produkt i poprawna domyślna porcja, dwie miarki na 35 gramów, dokładnie jak na opakowaniu. Świetnie, temat zamknięty? Niestety niezupełnie. Okazało się, że darmowy plan FatSecret, choć bardzo hojny, obsługuje wyłącznie kody amerykańskie — a około połowy użytkowników Amy mieszka poza Stanami. To poważny problem.
Sprawdziłem więc produkty spoza USA. Skanowałem na przykład wodorosty, które miałem pod ręką — FatSecret poradził sobie słabo. Open Food Facts rozpoznał produkt poprawnie, z porcją i dokładniejszym opisem. Po serii kolejnych prób wyłoniła się ciekawa zależność: Open Food Facts ma znacznie lepszą bazę międzynarodową i opisy, ale bywa niepewny co do domyślnej porcji. FatSecret trafia w porcje produktów amerykańskich, jednak kuleje przy markach zagranicznych, a czasem po prostu zmyśla nazwy — raz „wyprodukował” „Polar Pomegranate Seltzer”. Nie mam zielonego pojęcia, skąd to wytrzasnął.
Ostateczny układ: dwie bazy i tani model w roli sędziego
Żadna z usług nie wygrywała jednoznacznie, więc zamiast wybierać, połączyłem obie. Gdy użytkownik skanuje kod, aplikacja odpytuje równolegle Open Food Facts i FatSecret, a następnie wykonuje jedno krótkie zapytanie do Gemini 2.5 Flash-Lite — bardzo taniego modelu — które porównuje wyniki i wybiera lepszą wartość domyślną. (Informacja dodatkowa: Flash-Lite to najtańsza odmiana Gemini 2.5, przeznaczona do prostych zadań masowych.) Komuś może się to wydać przerostem formy, ale przy marży w okolicach 85% spokojnie mogę ją nieco ścisnąć, jeśli użytkownik ma dostać lepszy rezultat.
Trzy przypadki brzegowe, które wyszły dopiero w kuchni
Uzbrojony w ten układ uznałem, że funkcja jest gotowa do wdrożenia. Dopiero codzienne korzystanie pokazało, co naprawdę trzeba było obsłużyć.
Przypadek pierwszy: prawie nikt nie je dokładnie jednej porcji. Raz dwie, raz pół. Potrzebowałem możliwości błyskawicznej zmiany wielkości porcji — a to zaskakująco trudne zadanie na gruncie interfejsu. Spędziłem dużo czasu na Mobbin (Informacja dodatkowa: Mobbin to popularna wśród projektantów biblioteka zrzutów ekranów aplikacji mobilnych, przydatna przy szukaniu sprawdzonych wzorców.), oglądając, jak mierzą to inni, aż w końcu zatrzymałem się przy rozwiązaniu wystarczająco dobrym.
Przypadek drugi: co, gdy kodu nie ma — na przykład ktoś go zerwał — albo skan nie zwraca żadnego wyniku? Wymyśliłem coś, czego nie widziałem u nikogo innego: gdy kodu nie da się rozpoznać, dotykacie przycisku i fotografujecie samą etykietę z wartościami odżywczymi, a sztuczna inteligencja odczytuje z niej kalorie i wszystkie makroskładniki. Logika prosta: jeśli macie opakowanie w dłoni, niemal na pewno macie też jego etykietę, więc w większości sytuacji to zadziała.
To z kolei wygenerowało przypadek trzeci. Skanowałem ostry sos i okazało się, że etykieta oplata butelkę dookoła — nie dało się jej uchwycić na jednym zdjęciu. Rozwiązanie: gdy model nie potrafi poprawnie odczytać etykiety, bo wygląda na uciętą, pojawia się nowy ekran z pytaniem, czy dokończyć serię zdjęć. Dokładacie kolejne ujęcia, aż etykieta jest w całości, aplikacja skleja wszystko w jedno i dopiero wtedy liczy. Tego pomysłu też nie spotkałem nigdzie indziej — i przyznaję, jestem z niego dumny.
Całość zajęła mnie znacznie więcej, niż zakładałem. Plan mówił o jednym dniu, a dostałem kilkudniową wyprawę w głąb szczegółów. I to jest właściwa lekcja tej historii: różnica między testowaniem a używaniem. Testując, brałem z półki losowe produkty i sprawdzałem, czy skan działa. Dopiero gdy zacząłem nosić aplikację na zakupy — z prawdziwymi artykułami, kodami na wpół podartymi albo ledwo czytelnymi — wyszły wszystkie pułapki. Cieszę się, że wyłapałem je przed premierą. Dla użytkowników byłyby to proste punkty zacięcia: usterka na starcie odbiera zaufanie do funkcji, a pewnie i do całej aplikacji. Na szczęście dane już napływają — widzę, że ludzie skanują.
Materiał partnera: WhisperFlow
Może zauważyliście, że w kilku ostatnich filmach wszystko dyktuję do Claude’a i Claude Code. I właśnie to jest moja pierwsza rada dla każdego, kto pracuje z Claude Code albo innym narzędziem do kodowania z pomocą AI: dyktujcie, nie piszcie. Prompt z głosu wychodzi po prostu znacznie bogatszy w szczegóły. Ja używam do tego WhisperFlow — i tu wielkie podziękowania za wsparcie tego odcinka. To inteligentny zamieniacz mowy na tekst, działający w każdej aplikacji, a dla programistów bezcenny, bo zna żargon techniczny. Mówię „AWS, DynamoDB, Gemini 2.5 Flash-Lite, Supabase” — i za każdym razem zapisuje wszystko poprawnie. W Cursorze czy Windsurf potrafi sam podpinać pliki: mówię „popraw style w subscription-overview.tsx”, a plik zostaje wskazany bez dotykania klawiatury. Działa na komputerze — więc przy Cursorze, Claude Code czy ChatGPT — a także na iOS i Androidzie; ja ciągle odpowiadam nim na wiadomości i komentarze pod filmami. Link zostawiam w opisie wraz z kodem na dodatkowy miesiąc zdarma ponad czternastodniowy okres próbny WhisperFlow Pro. Nie musieli tego robić — sam ich o to prosiłem, więc jeszcze raz dziękuję.
Śledzenie wody: funkcja stworzona pod własne potrzeby
Po tej wyprawie w świat kodów kreskowych potrzebowałem oddechu i czegoś przyjemniejszego. Zbudowałem więc funkcję, o którą nie prosił praktycznie nikt: śledzenie wody. Ostatnio mnóstwo podróżuję i bez przerwy zapominam pić. Co chwilę myślałem: „szkoda, że Amy tego nie ma”, aż w końcu mnie olśniło: „czekaj, to moja aplikacja — mogę dodać, co chcę”. No i dodałem, rozwiązując własny problem.
Koncepcja była od początku klarowna: wpisuję, co wypiłem, po prawej pojawia się ilość wody — zupełnie jak kalorie przy jedzeniu — a na dole ekranu mały wskaźnik pokazuje dzienną sumę. Zaimplementowałem to szybko, dodałem też widok całości dnia po stuknięciu wskaźników.
Skoro poszło tak gładko, postanowiłem pomęczyć interfejs nieco mocniej, żeby funkcja jakoś wystawała ponad przeciętność. Bo bądźmy szczerzy: było nudnawo. Poprawne, działające — ale wiedziałem, że mogę lepiej. Przetestowałem kilka koncepcji. A co, gdyby dzienny widok wyglądał jak butelka? Delikatnie falująca linia wody, a na niej unosząca się gumowa kaczuszka. Pobawiłem się jeszcze kilkoma wariantami, ale coś nie grało — całość czuła się jak zupełnie obca aplikacja. Ostatecznie wylądowałem na stonowanej wersji: linia wody i kaczuszka zjechały do stopki ekranu.
Pod maską: dlaczego odrzuciłem słowa kluczowe
Na moment odłożyłem wygląd, bo dostrzegłem problem z mechaniką. Zanim o nim opowiem, pokażę, co się dzieje, gdy użytkownik cokolwiek wpisuje w Amy — kazałem Claude Code narysować cały ten przebieg i wygląda on wręcz zatrważająco. To pełna droga tekstu w dwóch–trzech sekundach od wpisania do pojawienia się kalorii. Zabawne, ile złożoności schowało się za tak prostym ekranem.
Samą detekcję wody Claude Code zaproponował zrobić tak: w potoku przetwarzania szukamy konkretnych słów — „water”, „H2O”, „oz”, „fluid ounces” — a gdy któreś się pojawi, wyciągamy ilość na przykład wyrażeniami regularnymi i wpisujemy do aplikacji. Jest w tym jedna zasadnicza dziura: ponad połowa użytkowników Amy nie mieszka w USA i wpisuje teksty nie po angielsku. Takie dopasowywanie słów rozsypałoby się przy pierwszym lepszym wpisie w innym języku, a ja nie zamierzałem komponować słowników dla każdej mowy świata. Warstwa rozpoznawania musiała być całkowicie niezależna od języka.
Zdecydowałem się więc na bardzo lekkie zapytanie do Gemini 2.5 Flash-Lite, które rozstrzyga: czy to wpis o wodzie, czy o jedzeniu? Jeśli woda — puszczamy go osobną ścieżką, z kolejnym zapytaniem do tego samego taniego modelu wyciągającym ilość. Najbardziej wykrętny przypadek brzegowy: ktoś wpisuje jedzenie i wodę naraz — „dwa jajka i szklanka wody”. Tu właśnie okazała się przewaga rozpoznawania przez model językowy: potok ogarnia takie mieszanki bez specjalnych sztuczek. Ceną jest to, że przy każdym wpisie w Amy leci teraz sporo wywołań. Gdy wszystko zadziałało i przestało się sypać w testach, wróciłem do szlifowania interfejsu.
Detale, które robią różnicę
Kilka rzeczy doszło prosto z życia. Kalendarz na górze — bo w praktyce wciąż chciałem zajrzeć kilka dni wstecz i zobaczyć, ile piłem w całym tygodniu. Przestało też bawić stukanie w kółko „32 oz Stanley cup” (Informacja dodatkowa: Stanley to kultowe w USA kubki termiczne; 32 oz to około 950 ml.) — dodałem więc własne butelki. Jest szybkie dodawanie: klikacie plus, wyskakuje arkusz z zapisanymi butelkami, wybieracie i wpis zapisuje się natychmiast. Do tego widget na ekranie głównym z przyciskiem otwierającym szybkie wpisywanie oraz strona celów, na której ustawiacie dzienny limit i jednostki.
Na końcu wciągnąłem Cecylię do przygotowania pięknych, autorskich ilustracji — do widgetu i strony celów — a gumową kaczuszkę zamieniłem na rysunek Amy na dmuchanym kole. A mój absolutny ulubiony akcent: animacja reagująca na przechylenie telefonu. Obracacie urządzenie, a woda i Amy przechylają się w jego stronę. Nie macie pojęcia, jak bardzo się cieszyłem, gdy to zadziałało.
Ostatnia decyzja: całość jest w pełni opcjonalna. Przy rejestracji można wodę włączyć lub wyłączyć, a gdy jest wyłączona, użytkownik nie ma pojęcia, że taka funkcja istnieje — żadnych wskaźników, żadnego menu szybkiego dodawania. Bonus dla mnie: przy wyłączonej opcji backend w ogóle nie próbuje wyciągać wody z wpisów, więc trochę oszczędzam.
To zresztą część mojej ogólnej filozofii — przy Amy i wszystkich moich aplikacjach: trzymać prostotę na krótkiej smyczy. Użytkownicy proszą o śledzenie cukru, kofeiny czy alkoholu; to tematy, które chcę kiedyś ruszyć, ale muszę uważać, żeby nie przeładować interfejsu i nie skomplikować aplikacji. Dlatego pewne funkcje wdrażam jako całkowicie opcjonalne i domyślnie wyłączone.
Najmniej spektakularne prace, prawdopodobnie najważniejsze
Szczerze mówiąc: skaner kodów i woda to były te przyjemniejsze projekty, ale o retencji może decydować to, co opowiada się najgorzej.
Po pierwsze, dokładność. Gdy wpisujecie „burrito z kurczakiem”, a aplikacja podaje złe kalorie, natychmiast tracicie do niej zaufanie — i odchodzicie. Włożyłem w podnoszenie trafności Amy mnóstwo pracy; spokojnie starczyłoby na osobny film, więc dajcie znać w komentarzach, czy chcecie.
Po drugie, garść drobnych usprawnień interfejsu. Małe usterki i papierkowe irytacje pojedynczo nie wyglądają na problem, ale po zsumowaniu realnie zwiększają tarcie — i ludzie odpadają. Najlepszy przykład: zgłoszona przez użytkownika usterka, której tygodniami nie potrafiłem odtworzyć. Lewa kolumna z tekstem i prawa z kaloriami czasem rozjeżdżały się przy przewijaniu: lewa jechała, prawa stała w miejscu. Nadzwyczaj irytujące. Gdyby przydarzyło mi się to kilka razy, sam bym odinstalował.
Wszystko, co zrobiłem w ostatnich dwóch tygodniach — naprawione drobiazgi, wyższa dokładność i nowa droga wpisywania w postaci skanera — powinno podnieść retencję tygodniową. Niestety dowiem się tego dopiero za kilka tygodni, a wtedy wrócę do was z raportem.
Amy po pięciu miesiącach: bilans
Tyle jeśli idzie o stan aplikacji po pięciu miesiącach. Mamy około 2800 dolarów miesięcznego przychodu powtarzalnego, 3000 dolarów z ostatnich trzydziestu dni i 13% retencji tygodniowej — co boli podwójnie, bo jeszcze miesiąc temu byłem przekonany, że mam 20%. Patrząc z drugiej strony: oznacza to po prostu mnóstwo miejsca do poprawy. Jeśli podoba się wam ten format, wpadnijcie na mój Instagram i TikTok — prawie co drugi dzień wrzucam tam coś o budowaniu aplikacji. I oczywiście zasubskrybujcie kanał. Dziękuję bardzo za obejrzenie — do zobaczenia w następnym odcinku.