O projekcie i kliencie#
Stworzyć intuicyjny w użytkowaniu produkt oparty na wiedzy rynkowej Klienta, który usprawnia rynek opieki nad bliskimi poprzez skuteczne łączenie osób potrzebujących wsparcia z dopasowanymi opiekunami z okolicy — w kilka minut, bez pośredników, oszczędzając czas obu stron oraz zapewniając klarowny wgląd w szczegóły dopasowanych profili.
Współpraca z zespołem od samego początku stała na bardzo wysokim poziomie. Najbardziej doceniam ich profesjonalizm, zaangażowanie oraz stały kontakt na każdym etapie realizacji projektu. Zawsze wiedziałem, na jakim etapie są prace, a każda kwestia była omawiana na bieżąco.
To, co zrobiło na mnie największe wrażenie, to sposób, w jaki podchodzili do moich pomysłów. Mogłem swobodnie przedstawić swoją wizję, nawet jeśli nie była w pełni dopracowana, a oni potrafili przełożyć ją na konkretne rozwiązania i zaproponować własne, często jeszcze lepsze koncepcje.
Z czym się mierzyliśmy#
Opiekly powstało w obszarze, który łączy wrażliwe dane, dwa różne typy użytkowników oraz złożony proces dopasowania opiekuna do potrzeb rodziny. Kluczowe wyzwania dotyczyły tego, jak uprościć bardzo złożoną decyzję wyboru opiekuna, jak bezpiecznie obchodzić się z danymi oraz jak zaprojektować jeden produkt dla dwóch różnych ról.
Jak porównać nieporównywalne kryteria?
Rodzina szukająca opiekuna bierze pod uwagę wiele rzeczy naraz: zakres pomocy, doświadczenie, lokalizację, dostępność i konkretne potrzeby zdrowotne. Wyzwanie polegało na tym, że te kryteria nie mają jednej wspólnej „wagi” — różni użytkownicy mogą inaczej oceniać ich znaczenie. Trzeba było więc zaprojektować sposób prezentowania wyników, który nie upraszcza decyzji w sztuczny sposób.
Wrażliwe dane w aplikacji
Aplikacja operuje na danych takich jak informacje zdrowotne, adres czy dane kontaktowe. Wyzwanie polegało na tym, jak pokazać użytkownikowi wystarczająco dużo informacji, żeby mógł podjąć decyzję, ale jednocześnie nie narazić ich na niepotrzebną ekspozycję lub nadużycie.
Kiedy założyć konto w procesie kreatora profilu?
Onboarding musiał znaleźć równowagę między prostotą rozpoczęcia a potrzebą weryfikacji użytkownika. Zbyt wczesne konto zniechęcało użytkowników, a zbyt późne powodowało utratę danych i brak możliwości kontaktu. Celem było znalezienie momentu, w którym użytkownik jest już zaangażowany, ale jeszcze nie „przytłoczony” przez formalności.
Dwie role w jednej aplikacji
Aplikacja obsługuje dwa różne typy użytkowników: rodziny i opiekunów. Wyzwanie polegało na tym, że mimo wspólnego systemu, obie grupy mają inne potrzeby, inne informacje i inny sposób korzystania z produktu — co trzeba było uwzględnić w jednym, spójnym doświadczeniu.
Przez cały czas współpracy z zespołem miałem poczucie, że dla każdego zagadnienia możemy wspólnie znaleźć rozwiązanie. Nigdy nie usłyszałem, że czegoś „nie da się zrobić” — zespół zawsze szukał sposobu, jak osiągnąć zamierzony efekt. Profesjonalne podejście było dla mnie najważniejsze i dawało ogromny komfort oraz zaufanie.
Macie podobnie złożony projekt? Pogadajmy.
Dopasowywanie, role, wrażliwe dane i skala — wiemy, jak to ułożyć w spójny produkt.
Jak podeszliśmy do projektu#
Cztery zasady, którymi prowadziliśmy projekt: najpierw rozmowa z klientem — wieloletnim praktykiem branży, potem kod. Prosty i skuteczny design — wielu użytkowników z grupy docelowej na co dzień nie korzysta z skomplikowanych aplikacji. Każdy etap dowozimy w całości — bazę, serwer i ekran w przeglądarce — żeby klient widział działającą funkcję, a nie szkic. Pytamy, kiedy nie wiemy — bo zależy nam na najlepszym produkcie, nie na efektownym demo.
Ustalenie kierunku razem z klientem-praktykiem branży
Zanim rozpoczęliśmy prace, wspólnie z klientem posiadającym wieloletnie doświadczenie w branży opieki doprecyzowaliśmy zakres produktu: listy zadań opiekuńczych, jednostki chorobowe oraz optymalną drogę użytkowników — od opisu potrzeby przez rodzinę, przez profil opiekuna, po kontakt. Uzgodniliśmy także wspólny język domenowy, co znacząco przyspieszyło dalsze etapy.
Prostota i intuicyjność interfejsu
Projektujemy dla użytkowników, którzy często nie korzystają na co dzień z aplikacji — zarówno po stronie rodzin, jak i opiekunów. Dlatego każdy ekran musi być zrozumiały na pierwszy rzut oka. Zamiast rozbudowanych formularzy stosujemy krótkie kroki, prosty język i jedną główną akcję na ekranie. Prostota nie jest tu elementem estetycznym, ale warunkiem dopasowania do grupy docelowej.
Działająca funkcja po każdej iteracji
Każda aktualizacja to działająca funkcja w przeglądarce, nie statyczne demo. Proces opiera się na krótkiej pętli: prezentacja, sugestie, iteracja. Każdy moduł dostarczany jest w całości — wraz z bazą danych, interfejsem i testami. Integracja prowadzona jest na bieżąco, bez odkładania jej na kolejne etapy.
Stały kontakt z klientem i wczesna walidacja założeń
Wiedzę branżową klienta traktujemy jako drogowskaz, dlatego utrzymujemy z nim stały kontakt na zawsze dostępnym łączu. Regularnie prezentujemy postępy i weryfikujemy założenia, zanim wejdziemy głębiej — dzięki temu ograniczamy ryzyko poważnych zmian na zaawansowanych etapie i szybko wprowadzamy sugestie i omawiamy pomysły.
Kluczowe widoki#
Kreator rejestracji to jeden ciągły widok podzielony na kilka kroków — od wyboru roli i typu opieki, przez mobilność i zakres zadań, aż po adres z promieniem obsługi. Kreator wygląda inaczej dla opiekuna i dla osoby szukającej opieki — każda rola ma własną ścieżkę. Poniżej kilka wybranych widoków z kreatora.
Co dostarczyliśmy#
Gotowa do uruchomienia platforma webowa z pełnym przepływem dla rodziny i opiekuna — obejmująca rejestrację, dopasowanie, bezpieczne konta i kontakt między użytkownikami.
Z pełnym przekonaniem mogę polecić ten zespół każdemu, kto szuka partnera, który nie tylko stworzy aplikację bądź napisze oprogramowanie, ale również wniesie własne doświadczenie, wiedzę i zaangażowanie jako bezcenną wartość do projektu.
Chcecie podobne wyniki u siebie?
Wstępna analiza i wycena w 48h. Bez zobowiązań — pierwszy krok zawsze po naszej stronie.
Decyzje, które zrobiły różnicę#
Decyzje techniczne, które najmocniej wpłynęły na jakość systemu. Stack nowoczesny, ale standardowy — bez egzotycznych zależności, łatwy w utrzymaniu i audycie.
API generowane z OpenAPI zamiast ręcznie utrzymywanych kontraktów
NestJS generuje specyfikację OpenAPI z kontrolerów i DTO, a frontend korzysta z automatycznie generowanego klienta (TypeScript, React Query, Zod). Dzięki temu OpenAPI jest jedynym źródłem prawdy.
Zmiana kontraktu w backendzie natychmiast powoduje błąd kompilacji na froncie, eliminując rozjazdy typów i błędy runtime.
Logika dopasowania przeniesiona do warstwy bazy danych
Algorytm (filtry, dystans haversine, pokrycie zadań i ranking) realizowany jest w jednym zapytaniu SQL. Aplikacja otrzymuje już posortowany wynik, bez dodatkowego przetwarzania w JS.
Takie podejście eliminuje koszt transferu danych i zapewnia skalowalność przy rosnącej liczbie opiekunów.
Sentry jako źródło prawdy o stabilności aplikacji
Sentry monitoruje błędy runtime we frontendzie i backendzie. Odpowiedź na pytanie o stabilność: co się wywala, gdzie w stacku, u ilu użytkowników, w jakiej wersji.
Source maps i Sentry tunnel dają czytelne stack trace'y i omijają adblockery, dzięki czemu obraz błędów pokrywa realną populację.
PostHog jako miara używalności produktu
PostHog analizuje zachowanie użytkowników i konwersję w produkcie. Odpowiedź na pytanie o używalność: które ścieżki działają, gdzie użytkownicy się zatrzymują, które funkcje faktycznie są używane.
Wspólne definicje eventów utrzymywane są we współdzielonym enumie, co eliminuje rozjazdy analityczne między frontendem, backendem i dashboardami.
Feedback zbierany w punktach realnej interakcji z produktem
Ankiety uruchamiane są po kluczowych akcjach (np. wysłanie zapytania, odsłonięcie kontaktu), zamiast stałych widgetów.
System działa w dwóch trybach: z consentem (pełna integracja z PostHog) oraz bez consentu (anonimowe eventy bez identyfikacji użytkownika, bez możliwości łączenia sesji).
Tech stack#
Wybór bibliotek wokół decyzji powyżej. Standardowe, dobrze utrzymywane, bez ryzyka osierocenia.
FRAMEWORK · NAWIGACJA
JĘZYK
UI & STYLING
STAN, DANE I CODEGEN
BACKEND & DB
AUTH · POWIADOMIENIA
OBSERWOWALNOŚĆ I ANALITYKA
INFRA & DEVOPS
Środowiska i drogi do produkcji#
Cztery środowiska, każde z innym zakresem zaufania. Build i deploy zautomatyzowane przez GitLab CI/CD, tagi obrazów niezmienne dla każdego commita — nigdy nie da się przypadkiem nadpisać działającego obrazu.