GRO
Własna aplikacja do zarządzania rozwojem: spokojna przestrzeń bez paneli z metrykami i bez presji postępu mierzonego procentami. Zaprojektowana i budowana z pomocą AI, jednocześnie produkt i eksperyment z narzędziami.
Zobacz aplikację ↗
- Title
- GRO - własna aplikacja do zarządzania rozwojem
- Industry
- Productivity / Personal Development, B2C
- Role
- Product Design, budowanie z AI
- Tools
- Figma, Lovable, ChatGPT, Claude, Claude Code
- Date
- 2025 – 2026
Skąd się wzięła
Szukałam czegoś lekkiego.
Takiej aplikacji nie było.
Cele trzymałam w notesie albo w głowie. Notes nie pozwala zobaczyć postępu. Można w nim zapisać co chcę osiągnąć, ale nie widać czy cokolwiek faktycznie do tego zmierza. Głowa jeszcze gorzej. Cele bez miejsca, w którym żyją, po prostu się gubią albo zostają na poziomie ogólnego „chciałabym kiedyś”.
Próbowałam Notion. Jest tam wszystko: bazy danych, widoki, szablony, relacje między tabelami. Żeby zacząć faktycznie pracować z celami, trzeba najpierw spędzić kilka godzin na budowaniu struktury. Potem kilka kolejnych na jej poprawianiu. Aplikacja, która miała mi pomagać w rozwoju, sama stała się projektem do zarządzania.
Szukałam czegoś lekkiego, co nie narzuca sposobu pracy i nie stresuje panelami z metrykami, ale pozwala planować konkretne działania na każdy dzień i widzieć jak te działania przekładają się na postęp w celach. Aplikacji, która mówi o małych krokach, które można robić każdego dnia, a nie o tym ile procent celu zostało zrealizowane. Takiej aplikacji nie znalazłam. Więc zrobiłam własną.
Rola
Cztery role w jednej osobie
W większości projektów te role należą do różnych osób. W GRO wszystkie cztery były moje, co zmieniło sposób podejmowania decyzji: bez przekazywania tematu dalej, bez czekania na cudzą zgodę, z pełną odpowiedzialnością za każdy wybór.
Analityk
Zaczęłam od dokumentu analitycznego: wizja, model mentalny, analiza rynku aplikacji produktywnościowych i porównanie konkurencji. Zanim powstał pierwszy ekran, wiedziałam jaki problem rozwiązuję i czym GRO ma się różnić od tego co już jest.
Product Owner
Zdefiniowałam zakres i pilnowałam go. Każda funkcja musiała obronić swoje miejsce, a odrzucenie paneli z metrykami, serii czy grywalizacji to były decyzje produktowe poparte powodem, nie kwestia gustu.
Projektant
System kolorów, architektura informacji, przepływy i sposób, w jaki produkt prowadzi przez dzień. Tu zapadały decyzje o tym jak GRO mówi do użytkownika.
Pierwszy użytkownik
Używam GRO codziennie od stycznia 2026. Testuję sama, za to bez przerwy i bez taryfy ulgowej: funkcja, która nie sprawdzała się w realnym dniu, wypadała szybciej niż w jakimkolwiek procesie z klientem.
Problem
Rynek aplikacji productivity
Rynek oferuje dziesiątki rozbudowanych narzędzi pełnych funkcji, paneli z metrykami i powiadomień. Problem polega na tym, że zamiast porządkować myśli, generują nowy chaos poznawczy. Pracownicy wiedzy przełączają się między aplikacjami ponad 1 200 razy dziennie i tracą do 4 godzin tygodniowo tylko na zmianę kontekstu. Po każdym przerwaniu potrzeba średnio 23 minut na powrót do pełnej koncentracji.
Wzorzec porzucania
entuzjazm przy starcie → tygodnie konfigurowania systemu → zmęczenie utrzymaniem narzędzia → powrót do notatnika
Konkretne problemy narzędzi, które sprawdzałam
→Notion
Ma krzywą uczenia, która trwa tygodnie. 18% z ponad 5 700 recenzji na G2 wymienia ją jako główną wadę. Narzędzie zachęca do obsesji na optymalizacji: widoków, szablonów, baz danych. Użytkownicy spędzają więcej czasu na konfigurowaniu systemu niż na pracy, do której ten system miał służyć.
→Obsidian
To potężne narzędzie dla osób, które lubią budować własne systemy. 2 500 pluginów to jednocześnie jego siła i pułapka: utrzymanie działającego vaultu staje się projektem samym w sobie.
→Todoist i Things 3
Sprawdzają się do zarządzania zadaniami, ale są wąskie. Wszystko musi być taską. Nie ma miejsca na cele długoterminowe, wiedzę, regenerację.
→Aplikacje do śledzenia celów
Strides, Goalify, Habi obsługują jeden obszar. Nie planują dnia, nie obsługują wiedzy. Użytkownik i tak składa system z kilku narzędzi i ponosi koszt przełączania między nimi.
Żadne z tych narzędzi nie łączyło jednocześnie celów długoterminowych, planowania operacyjnego i intencjonalnego przyswajania wiedzy. Dlatego powstało GRO.
Architektura informacji
Cele są kręgosłupem
GRO ma cztery moduły, ale nie leżą obok siebie jak zakładki. Cele są kręgosłupem. Bloki w Daily Plan i treści w Content są przypisane do konkretnych celów, a ich wykonanie zasila postęp celu. Well-being stoi z boku i jest zawsze opcjonalny.
Dlaczego
Growth · Cele
kierunek rozwoju i postęp
↑ wykonane bloki zasilają postęp celu
↑ treść przypisana do celu
Co i kiedy
Daily Plan · bloki
typ aktywności + przypisany cel
Jak
Content · wiedza
źródła przypisane do celu
Well-being · regeneracja. Warstwa „Jak”, zawsze opcjonalna, z boku przepływu.
Postęp celu nie jest deklaracją. Wynika z tego, co realnie zostało zaplanowane i odhaczone w planie dnia.
Produkt i filozofia
Trzy warstwy, jeden kierunek
Aplikacja opiera się na trzech warstwach, ale nie są równorzędne. Cele są najważniejsze. Planowanie dnia i moduł treści są podporządkowane temu co użytkownik chce osiągnąć, a nie odwrotnie.
Dlaczego
Growth
Miejsce definiowania kierunku rozwoju. Każdy cel ma nazwę, opis i kolor wybrany przez użytkownika. Duże cele można rozłożyć na konkretne kroki, co sprawia, że nie zostają tylko deklaracją. Postęp jest liczony automatycznie na podstawie wykonanych bloków w planie dnia. Nie trzeba oceniać czy „idzie”. Widać to przez to, co zostało faktycznie zrobione.
Co i kiedy
Daily Plan
Planowanie na każdy dzień, tydzień, miesiąc, rok, na taki okres jaki jest potrzebny. Każdy blok ma typ i można przypisać go do konkretnego celu. Bloki mogą się powtarzać w dowolnym schemacie. Dzięki temu przy każdym zaplanowanym działaniu widać nie tylko co się robi, ale po co i jak to łączy się z tym co ważne długoterminowo.
Jak
Content
Moduł treści nie jest osobną biblioteką do przeglądania. Artykuły i źródła są tu dlatego, że pomagają w konkretnych celach, co zmienia relację z czytaniem. Zamiast nieskończonej kolejki do odrobienia, jest wiedza potrzebna tu i teraz. Artykuły, na które nie ma czasu, AI streszcza. Można przeczytać skrót i wrócić do pełnej wersji kiedy indziej.
Jak
Well-being
Własne praktyki regeneracyjne: oddech, spacer, cokolwiek. Można dodać do planu, ale to zawsze wybór. Well-being jest zawsze opt-in i nigdy nie staje się kolejnym obowiązkiem z poczuciem winy za niezalogowane działania.
Zakres produktu
Czego świadomie nie ma
Najtrudniejsza część projektowania GRO to nie było co dodać, tylko czego nie dodawać. Rynek pokazuje, że to właśnie nadmiar funkcji zabija te aplikacje. Każda funkcja, która nie trafiła do produktu, była rozważona i odrzucona z konkretnego powodu.
Funkcja
Decyzja
Dlaczego
Panele z metrykami i procentami
Poza zakresem
Stresują samą strukturą. Postęp ma być widoczny przez wykonane bloki, nie przez procent do odhaczenia.
Serie i passy
Poza zakresem
Jeden dzień przerwy kasuje serię i zostawia poczucie winy. Zniechęca zamiast motywować.
Grywalizacja (punkty, odznaki)
Poza zakresem
Rozwój osobisty to nie gra. Nagrody przesuwają uwagę z celu na zbieranie punktów.
Funkcje społecznościowe
Poza zakresem
GRO jest osobiste. Porównania z innymi to dokładnie ta presja, której unikam.
Powiadomienia o zaległościach
Poza zakresem
Aplikacja nie ma walczyć o uwagę ani przypominać o długach do nadrobienia.
Well-being jako stały moduł
Opt-in
Regeneracja z przymusu przestaje być regeneracją.
To, co zostało, da się streścić w jednym zdaniu: cele, plan dnia powiązany z celami, wiedza pod cele i regeneracja na własnych warunkach.
Kluczowe decyzje projektowe
Co i dlaczego zdecydowałam
Brak paneli z metrykami
To była świadoma decyzja projektowa. Aplikacje produktywnościowe często stresują użytkownika swoją strukturą: procentami ukończenia, seriami które przepadają po jednym dniu przerwy, czerwonymi alertami o brakujących działaniach. W GRO postęp jest widoczny przez to co zostało zaplanowane i faktycznie wykonane, bez porównywania do założonego celu dziennego.
Content powiązany z celami
Moduł treści mógłby działać jak ogólna biblioteka: lista artykułów do przeczytania, źródła do przeglądania, kanał treści bez konkretnego kontekstu. Zdecydowałam że nie o to chodzi. Dodając artykuł albo źródło, przypisujesz je do konkretnego celu. Jeśli pracujesz nad rozwojem zawodowym, treści z tego obszaru są widoczne przy tym celu, a nie w osobnym stosie do przejrzenia kiedy indziej. Wiedza ma miejsce, do którego należy, i jest dostępna tam gdzie jest potrzebna.
Well-being zawsze opt-in
Praktyki regeneracyjne nie pojawiają się jako obowiązek, nie generują alertów kiedy nie są wykonywane, nie psują żadnej serii. Użytkownik dodaje je do planu kiedy chce, albo w ogóle ich nie używa.
Flow
Jeden dzień z GRO
Każdy blok w planie dnia jest powiązany z konkretnym celem, więc planując dzień widać od razu jak poszczególne działania składają się na szerszy kierunek.
Rano
Otwieram widok dnia. Widzę zaplanowane bloki z poprzedniego dnia lub tygodnia, każdy z typem i przypisanym celem. Jeśli pojawia się coś nowego, dodaję blok i od razu przypisuję go do celu. Treści zaplanowane na dziś są w osobnej sekcji. Mogę przeczytać artykuł albo streszczenie AI jeśli czasu brakuje.
W ciągu dnia
Oznaczam wykonane bloki. Postęp celu aktualizuje się automatycznie. Nie trzeba nic liczyć ani wpisywać. Praktykę regeneracyjną dodaję jeśli chcę, nie dlatego że system pyta czy ją zrobiłam.
Tygodniowo / miesięcznie
Widok tygodnia pokazuje rozkład bloków, widać od razu czy czas idzie na to co ważne, czy gubi się w innych miejscach. Widok miesiąca i roku daje perspektywę na cele długoterminowe i bloki które powtarzają się w schemacie.
Co się zmieniło
Cele stały się jaśniejsze. Postęp w tych celach większy, bo mogę planować na każdy dzień, na miesiąc, na rok, na taki okres jaki jest potrzebny. Kontekst małych widocznych kroków działa lepiej niż ogólne „mam cel gdzieś w głowie”.
Proces
Proces budowania z AI
GRO powstało bez tradycyjnych makiet. Zamiast projektować ekrany i przekazywać je do wdrożenia, budowałam działający produkt od razu, a narzędzia AI były na każdym etapie.
- 1
Dokument analityczny
Pełny spec funkcjonalny jako jedyne źródło prawdy: wizja, model mentalny, benchmark rynku i opis każdego modułu krok po kroku. Samą analizę prowadziłam z pomocą Claude: porządkowanie wniosków, kwestionowanie założeń, ostrzejsze nazwanie problemu. Problem i pozycja GRO zdefiniowane, zanim powstał pierwszy ekran.
- 2
Model mentalny
Trzy warstwy: Dlaczego (Growth), Co i kiedy (Daily Plan), Jak (Content i Well-being). Hierarchia jasna: cele najpierw, reszta im służy.
- 3
Zakres i decyzje
Ustalenie zakresu MVP: które funkcje wchodzą, a które świadomie odpadają i dlaczego. Najtrudniejsze decyzje dotyczyły tego, czego nie budować, żeby produkt został spokojny.
- 4
Architektura danych
Supabase i relacja cel ↔ blok jako fundament. To ona pozwala liczyć postęp z wykonanych bloków, nie z deklaracji.
- 5
Build w Lovable
Szybkie postawienie działającej aplikacji: logika, flow, baza. Tu projekt i implementacja dzieją się razem, bez osobnych makiet: decyzje wizualne zapadają w trakcie budowania. Weryfikacja w praktyce, czy architektura informacji się broni.
- 6
Test na sobie
Codzienne użycie od stycznia 2026. Najlepszy filtr: funkcja, która nie działa w realnym dniu, wypada. Tak powstała największa poprawka: system kolorów zbudowałam, sprawdziłam w użyciu i przeprojektowałam, gdy okazało się, że kolory celów mylą się z kolorami typów.
- 7
Migracja do Claude Code
Następny etap eksperymentu: praca z komponentami z Figmy i dopracowanie warstwy wizualnej.
Lovable sprawdził się w szybkim budowaniu działającego produktu, ale ma granicę: nie umie w dopracowane komponenty i nie łączy się z Figmą tak, żeby projektować i budować jednocześnie. Dlatego kolejnym krokiem jest Claude Code, gdzie można wziąć to co zaprojektowano w Figmie i bezpośrednio z tym pracować.
Ten kontakt z ekosystemem AI i narzędziami no-code wpływa bezpośrednio na codzienną pracę projektową. Inaczej rozmawia się z deweloperami, kiedy samemu przeszło się przez budowanie produktu od środka.
Wnioski
Czego nauczył mnie ten projekt
Cele stały się jaśniejsze. Postęp w tych celach większy, bo mogę planować na każdy dzień, na miesiąc, na rok, na taki okres jaki jest potrzebny. Kontekst małych widocznych kroków działa na mnie lepiej niż ogólne „mam cel”.
Z perspektywy narzędzi: Lovable pozwolił szybko zbudować działający produkt i zweryfikować architekturę w praktyce. Pokazał też gdzie jest granica tego podejścia: w jakości komponentów i w integracji z procesem projektowym. Claude Code to następny test w tym samym eksperymencie.
Projektując GRO dla siebie, miałam jeden punkt odniesienia: czy po otwarciu aplikacji czuję spokój i wiem co zrobić, czy czuję presję i szukam gdzie zacząć. To drugie oznaczało że coś wymaga zmiany.