Frinter.app — Focus OS dla twórców

Po co powstał Frinter?

Większość narzędzi do produktywności rozwiązuje jeden problem naraz. Timer mierzy czas, tracker liczy dni, notes trzyma zadania. Ale praca twórcza nie działa w izolacji. Skupienie zależy od snu. Energia wpływa na jakość decyzji. Regularne rytuały decydują o długofalowych wynikach.

Frinter to próba zbudowania jednego systemu, który łączy te elementy — i który od początku był projektowany z myślą o tym, że będzie rósł.

Główne moduły:

• FRINT — timer do pracy głębokiej: bloki czasowe, tryb bez limitu, działanie w tle bez gubienia stanu
• Tracker aktywności — miesięczna siatka dni z danymi o śnie, energii i trzech sferach życia
• Dashboard energii — tygodniowy przegląd: czas pracy, regeneracja, proporcje między sferami
• Bullet Journal — planowanie codzienne, cykliczne, priorytety i notatki wdzięczności
• Gamifikacja — punkty, poziomy i odznaki budujące nawyk regularności
• Społeczność — rankingi, obserwowanie innych, leaderboardy
• AI asystent — chatbot z dostępem do danych użytkownika, oparty na Claude (Anthropic)

Cały system organizuje życie wokół trzech sfer:

• Rozkwit — zdrowie, sen, aktywność, medytacja, nauka
• Relacje — rodzina, przyjaciele, partner, społeczność
• Praca Głęboka — tworzenie, strategia, projekty wymagające pełnej koncentracji

15 miesięcy budowania — etap po etapie

Frinter powstawał iteracyjnie, ale zawsze z jednym założeniem: każda decyzja architektoniczna musi mieć sens nie tylko dziś, ale i przy dziesięciokrotnie większej skali.

Marzec 2025 — prototyp. Start na platformie Replit — szybkie środowisko do walidacji pomysłu. Cel: sprawdzić, czy produkt ma sens, zanim zainwestuję czas w “perfekcyjną” architekturę. Kilka tygodni, pierwszy timer, podstawowy tracker, pierwsze dane.

Sierpień–listopad 2025 — pełny produkt. Do prototypu doszły: rankingi, gamifikacja, onboarding, panel administratora, AI asystent i fundament aplikacji mobilnej. Frinter stał się produktem z kilkoma modułami — i pierwszym momentem, w którym zaczęło być ważne, jak te moduły są ze sobą połączone.

Grudzień 2025 — pierwsze wdrożenie produkcyjne. Migracja na Railway.app — prawdziwy serwer, baza danych, automatyczny deployment. Ten etap ujawnił pytanie, które zdefiniowało dalszy kierunek: jak zbudować backend, który będzie łatwy do skalowania niezależnie po każdej domenie?

Luty–marzec 2026 — projektowanie z myślą o skali. Zamiast czekać na problemy, zaprojektowałem architekturę docelową od zera. Z pomocą AI (Claude) powstały specyfikacje, plany migracji i mapy granic domenowych. Kluczowe pytanie: gdzie przebiega granica między core produktu, społecznością a AI — i jak ją zaprojektować tak, żeby każdy element mógł skalować się niezależnie?

Marzec–czerwiec 2026 — Cloudflare-native. Implementacja zaprojektowanej architektury: przepisanie backendu na Cloudflare Workers, wprowadzenie Service Bindings jako komunikacji wewnętrznej, podział produktu na niezależne domeny połączone przez bindings. Efektem jest system gotowy do skalowania bez przepisywania — każda część rośnie niezależnie.

Jak działa technicznie

Frinter jest zbudowany jak dobrze zaplanowane miasto: jeden główny wjazd dla wszystkich użytkowników, a ruch rozdzielany do odpowiednich “dzielnic” wewnątrz. Każda dzielnica może rosnąć niezależnie — bez blokowania pozostałych.

← przewiń →

Strona publiczna (frinter.app) — statyczna, ładuje się błyskawicznie, indeksowana przez Google. Oddzielona od aplikacji, żeby zmiany w produkcie nie wpływały na SEO i marketing.

Główna aplikacja (web.frinter.app) — timer, tracker, dashboard, journal. Działa jako PWA — można ją zainstalować na telefonie i korzystać jak z natywnej aplikacji. Dedykowana aplikacja mobilna na iOS i Android (Expo / React Native) jest aktualnie w budowie.

Jeden punkt wejścia API (api.frinter.app) — jedyna brama między klientem (web, mobile) a serwerami. Ukrywa wewnętrzną złożoność systemu. Klient rozmawia z jednym adresem; co jest w środku, może ewoluować bez zmian po stronie frontendu.

Niezależne domeny wewnętrzne — publiczny ruch trafia przez jeden API gateway. Wewnętrzne domeny produktu są rozdzielone na osobne workery połączone przez Cloudflare Service Bindings:

• core — timer, tracker, profil: serce produktu, musi być zawsze niezawodny
• auth — uwierzytelnianie: osobna domena z własnym modelem bezpieczeństwa
• community — rankingi, społeczność, odznaki: może skalować się niezależnie od core
• AI — chatbot i rekomendacje: eksperymenty AI nie wpływają na stabilność core

Dzięki temu każda część może być rozwijana, skalowana i izolowana niezależnie.

Przechowywanie danych:

• PostgreSQL (Neon) — główna baza danych: source of truth dla wszystkich danych użytkownika
• Cloudflare KV — szybka pamięć podręczna: rankingi i statystyki dostępne w milisekundy
• Cloudflare R2 — pliki i artefakty: zdjęcia, eksporty, dane AI

Decyzje projektowe

Granice domenowe od początku. Frinter mógł być jednym monolitem. Wybrałem inaczej: każda kluczowa domena (auth, core, community, AI) ma własny runtime. Awaria rankingów nie wpływa na timer. Eksperyment z AI nie blokuje trackera. To decyzja projektowa, nie reakcja na problemy.

Jeden publiczny punkt wejścia. Aplikacja mobilna i webowa rozmawiają z jednym API. Dzięki temu zmiany wewnętrzne — nowe workery, optymalizacje, migracje — nie wymagają aktualizacji klientów. Gateway jest stabilnym kontraktem między frontendem a backendową topologią.

Auth jako osobna domena. Bezpieczeństwo uwierzytelniania jest zbyt krytyczne, żeby dzielić runtime z resztą kodu produktu. Izolacja oznacza odrębną powierzchnię ataku i pełną kontrolę — bez ryzyka regresji z innych części systemu.

Monorepo dla pełnego kontekstu. Cały kod — web, mobile, wszystkie workery, pakiety współdzielone — żyje w jednym repozytorium. Refaktory są bezpieczniejsze. AI agenty mają pełny kontekst projektu. Typy i kontrakty między domenami są współdzielone i walidowane statycznie.

Skalowanie przez design, nie przez migrację. Cloudflare Workers skaluje automatycznie — bez konfiguracji load balancerów, bez ręcznego zarządzania instancjami. Separation of concerns na poziomie domen sprawia, że każda część może przyjmować ruch niezależnie od pozostałych.

Stack technologiczny

Co ten projekt pokazuje

Myślenie o skali od dnia pierwszego. Decyzje architektoniczne w Frinterze były podejmowane z wyprzedzeniem, nie jako reakcja na problemy. Granice domenowe, izolacja serwisów, jeden punkt wejścia API — każda z tych decyzji jest świadomym wyborem, który ma działać zarówno dziś, jak i przy znacznie większej skali.

AI jako narzędzie do projektowania, nie generowania. Najciekawszą częścią tego projektu jest sposób pracy z AI: Claude był używany do pisania specyfikacji architektonicznych, planowania migracji, mapowania granic domenowych i weryfikacji decyzji — nie tylko do generowania kodu. To pokazuje, jak używać AI metodycznie w procesie product engineering.

Full-stack delivery przez jednego inżyniera. Frinter to frontend web, PWA, kilka backendów, auth, bazy danych, storage, SEO, bezpieczeństwo i dokumentacja operacyjna. Aplikacja mobilna (Expo) jest aktualnie w aktywnym rozwoju. Jeden inżynier, jeden produkt, 15 miesięcy — od prototypu do architektury gotowej na skalę.

Produkt, nie tylko kod. Za techniczną warstwą stoi przemyślana filozofia produktu: trzy sfery, system energii, rytm pracy głębokiej. Frinter ma onboarding, design system, działającą aplikację web jako PWA i landing — bo dobry produkt to nie tylko dobrze napisany kod.