Zbudowałem własny dashboard porannej rutyny — oto jak i dlaczego

Rano otwierasz komputer. Jedna zakładka z newsami branżowymi, druga z ClickUpem, trzecia z kalendarzem, czwarta z kursem, do którego i tak nie wrócisz bo już wciągnęły cię maile. Godzina minęła, dzień się zaczął, a ty masz wrażenie że jeszcze nic nie zrobiłeś.

Znam to dobrze. Dlatego zbudowałem Morning Hub — jedno miejsce, które zbiera wszystko, co chcę zrobić rano, zanim dzień mnie wciągnie. W tym artykule opowiem skąd wziął się pomysł, co to narzędzie robi i jak — z kilkoma ciekawostkami technicznymi po drodze.

Fenomen Poranka — skąd się to wzięło

Wszystko zaczęło się od książki. Fenomen Poranka Hala Elroda to pozycja o budowaniu porannych rytuałów — autor proponuje konkretny zestaw praktyk: medytację, afirmacje, wizualizację, ćwiczenia, czytanie i pisanie.

Nie przejąłem tego przepisu jeden do jednego. Zamiast medytacji mam kurs. Zamiast afirmacji — szybki rzut oka na zadania, żeby wiedzieć na co dzień czeka. Ale idea trafiła do mnie: poranek to jedyna część dnia, nad którą mam pełną kontrolę, zanim wejdą w grę maile, spotkania i priorytety innych ludzi.

To było dla mnie wystarczające, żeby zadziałać. I skoro jestem programistą — zadziałałem kodując.

Moje bloki — co robi Morning Hub

Dashboard składa się z bloków, przez które przechodzę jeden po drugim. Każdy ma swoje miejsce, sens i zaplanowany czas na wykonanie:

Nowości z branży — RSS z wybranych źródeł. Zamiast przypadkowego scrollowania, mam kontrolowaną dawkę tego co dzieje się w świecie tech. Czytam przez 5-10 minut i idę dalej.

Laracasts — to mój najważniejszy blok. Każdego ranka przynajmniej jeden odcinek kursu. Nie zawsze mam czas na wszystko — ale Laracasts skończę zawsze. To mój osobisty kontrakt ze sobą.

JeżycJadło — mój side project, czyli rozbudowywana baza restauracji na Jeżycach w Poznaniu. Pięć minut dziennie to mało, ale regularność sprawia, że projekt żyje zamiast kurzyć się w szufladzie.

ClickUp ×3 — trzy osobne bloki: zadania prywatne, projektowe i pracowe. Pełny obraz dnia w jednym miejscu. Dodatkowy bonus: zanim wejdę na daily, mam już głowie poukładane co robię i co mogę zaraportować.

Google Calendar — ostatni blok, żebym nie zapomniał o wizycie u lekarza albo jakimś spotkaniu poza ClickUpem.

Na sam koniec: timer całego rytuału, żeby wiedzieć ile mi to zajęło.

Jak to powstało — historia techniczna

Prototyp w tydzień

Projekt zaczął się od jednego celu: chcę widzieć swoje zadania z ClickUpa w przeglądarce, nie w aplikacji ClickUp. Pierwszy działający prototyp — Laravel 12, Inertia v2, integracja z ClickUp API — powstał w niecały tydzień. Jak to zwykle bywa z side projectami, potem przez kilka miesięcy dodawałem kolejne rzeczy z doskoku: logowanie przez Google, integrację z Google Calendar, widok "zadania na dziś".

Punkt zwrotny — rezygnacja z Inertii

Gdzieś w trakcie zainteresowałem się możliwością zrobienia wersji mobilnej na Androida. I tu pojawił się problem: Inertia.js jest świetna do szybkiego startu, ale wiąże frontend z cyklem request-response Laravela. Jeśli kiedykolwiek chcę, żeby ten sam backend obsługiwał aplikację mobilną — muszę mieć czyste REST API.

Decyzja była prosta: migruję do pełnego SPA.

Zamiast jednej wielkiej zmiany, przepisywałem to stopniowo — commit po commicie:

• d62a596 — dodałem Vue Router, Axios, Pinia i usunąłem Inertię z zależności
• 5953a2a — usunąłem Inertię i Wayfinder, podłączyłem Google OAuth do nowej architektury
• dd26969 — ostatni commit migracji: usunięcie wszystkich pozostałych importów Inertii

Obecny stack:

Backend wystawia czyste REST API z Bearer tokenem — gotowe na każdego klienta, nie tylko przeglądarkę.

Czego się nauczyłem — co bym zrobił inaczej

Inertia nie była błędem. Pozwoliła mi postawić działający prototyp w tydzień bez myślenia o routingu po stronie klienta, zarządzaniu stanem czy interceptorach Axiosa. Jeśli chcesz szybko zwalidować pomysł — Inertia jest świetna.

Ale wiedząc co wiem teraz, zacząłbym od SPA od razu. Migracja nie była trudna technicznie, ale zajęła czas, który mógłem przeznaczyć na nowe funkcje. Jeśli od początku wiesz, że backend może obsługiwać inne klienty — warto zainwestować w REST API na starcie.

Co do samego procesu: budowanie side projectu w małych sprintach, z tygodniowymi lub miesięcznymi przerwami, działa lepiej niż próba ukończenia wszystkiego naraz. Projekt żyje i ewoluuje razem z potrzebami.

Codzienne używanie — po co to komu

Nie każdego ranka przechodzę przez wszystkie bloki. Czasem brakuje czasu, czasem energii. Ale Laracasts skończę zawsze. I to wystarczy — bo codziennie, zanim dzień mnie wciągnie, zrobiłem coś dla siebie. Coś, co choćby minimalnie pcha mnie do przodu.

To jest wartość, której żadne zewnętrzne narzędzie mi nie da tak dobrze jak to własne — dopasowane dokładnie do mojego rytmu, moich projektów, moich priorytetów.

Projekt jest open source:

• GitHub: github.com/rawendil/morning-hub
• Live demo: morning-hub.rawendil-md2.usermd.net (logowanie przez Google wymaga wcześniejszego dodania konta — napisz, to dodam)