Panel klienta VulCode

VulCode to nasza własna marka, więc ten panel budowaliśmy dla siebie i to okazało się najtrudniejszym możliwym klientem. Kiedy robisz coś dla siebie, nie ma się za kim schować: każde uproszczenie, każda liczba, która się nie zgadza, wraca prosto do Ciebie. Dlatego ten projekt od początku miał być wzorcem tego, jak w ogóle wygląda u nas panel klienta, a nie prowizorką na własny użytek.

Zadanie brzmiało prosto: dać klientowi jedno miejsce, w którym widzi wszystko, co go dotyczy, i sam załatwia sprawy, które wcześniej wymagały maila. W praktyce oznaczało to spięcie kilku światów naraz - stanu projektów, faktur, zgłoszeń wsparcia i programu partnerskiego liczącego realne pieniądze - w jeden spójny ekran, który działa tak samo na biurku i w kieszeni. Ten case study pokazuje, gdzie były prawdziwe pułapki i jak je obeszliśmy.

Zanim powstał panel, każde pytanie o etap projektu albo o dokument kończyło się mailem, a odpowiedź zależała od tego, kto akurat go odczytał i czy pamiętał kontekst. To nie skaluje się nawet przy kilkunastu klientach: ta sama informacja żyła w skrzynce jednej osoby, a klient czekał, zamiast po prostu spojrzeć.

Panel odwraca ten układ. Klient loguje się i od razu ma przed sobą swoje projekty ze statusem prac, listę faktur z tym, co zapłacone i co do zapłaty, oraz historię wszystkich zgłoszeń, jakie kiedykolwiek zgłosił. Nic nie trzeba wyszukiwać po mailach, bo źródłem prawdy jest jeden widok, a nie czyjaś pamięć.

Efekt jest odczuwalny po obu stronach. Klient przestaje czekać na człowieka, żeby dowiedzieć się rzeczy, które system i tak zna. Zespół przestaje odpisywać na te same pytania po raz setny, bo odpowiedź jest już na ekranie, zanim ktokolwiek zdąży ją wpisać.

Program partnerski wygląda niewinnie, dopóki nie zaczniesz liczyć prowizji na kwotach z groszami. Tu zaczynają się klasyczne dramaty: dziesięć procent z 19.99 zł policzone na liczbie zmiennoprzecinkowej potrafi dać trzy nieznacznie różne wyniki na liście prowizji, w portfelu i na wypłacie, a wtedy salda przestają się sumować i nikt nie ufa panelowi.

Dlatego pieniądze w całym panelu trzymamy jako liczby całkowite w groszach i każdą prowizję liczymy na intach. Nigdy nie ma tu ułamka złotówki, który mógłby się zaokrąglić raz w jedną, raz w drugą stronę. Jedna operacja, jedna reguła zaokrąglenia w dół, ten sam wynik wszędzie, gdzie ta kwota się pojawia.

Panel klienta pokazuje pieniądze i dokumenty, więc pytanie "kto ma prawo to zobaczyć" nie jest kosmetyczne. Klient ma widzieć wyłącznie swoje dane, zespół tylko to, do czego jest uprawniony, a granica między nimi nie może zależeć od tego, czy front akurat schował przycisk.

Zbudowaliśmy to na kontroli dostępu opartej na rolach i bezpiecznym uwierzytelnianiu, ale kluczowa decyzja jest architektoniczna: zakres tego, co można zobaczyć i zrobić, sprawdza backend na wejściu do API, a nie interfejs. Front może pokazywać albo chować, co chce, ale jeśli żądanie dotyczy cudzych danych, API odrzuca je, zanim w ogóle sięgnie do bazy.

To ta sama zasada, którą stosujemy wszędzie: granicy pilnuje się tam, gdzie wchodzą dane z zewnątrz, czyli na API, a nie liczy się na to, że użytkownik nie podmieni identyfikatora w adresie.

Klient nie siedzi cały czas przy komputerze. Fakturę sprawdza w tramwaju, na powiadomienie o zgłoszeniu reaguje z telefonu. Budowanie do tego osobnej aplikacji mobilnej oznaczałoby drugi kod do utrzymania i pewność, że prędzej czy później obie wersje się rozjadą.

Zamiast tego panel jest aplikacją webową, która instaluje się na telefonie jako PWA, z manifestem i service workerem. Ten sam kod, ten sam backend, ta sama logika prowizji. Na komputerze to pełny pulpit, na telefonie ikona na ekranie startowym i okno bez paska przeglądarki, zachowujące się jak natywna aplikacja.

Najłatwiej zrobić panel, który ładnie wygląda na przygotowanych z góry liczbach. Wygląda, dopóki ktoś nie kliknie i nie okaże się, że pod spodem nie ma nic. My poszliśmy odwrotnie: panel od pierwszego dnia stoi na prawdziwym backendzie, a każdy ekran pokazuje to, co faktycznie jest w bazie.

Ten wybór kosztuje więcej na starcie, bo trzeba mieć działające API, zanim cokolwiek się narysuje. Zwraca się jednak od razu, bo nie ma momentu "podłączymy dane później", w którym zwykle wychodzą wszystkie założenia, które nie przetrwały kontaktu z rzeczywistością. To, co widać w panelu, jest tym, co system naprawdę wie.

Klient dostaje jedno miejsce, w którym widzi swój stan i sam obsługuje sprawy, które wcześniej wymagały maila do zespołu. Wchodzi, sprawdza projekt, pobiera fakturę, odpisuje w zgłoszeniu, patrzy na saldo prowizji z programu partnerskiego, a jeśli akurat jest w drodze, robi to samo z telefonu, bo to ta sama aplikacja. Nic z tego nie zależy od tego, czy ktoś z zespołu jest akurat przy skrzynce.

Po naszej stronie zysk jest równie konkretny. Program partnerski działa bez ręcznego przeliczania czegokolwiek, bo pilnuje go kod na liczbach całkowitych, a nie arkusz, który ktoś musi domykać. Salda się zgadzają, bo nie ma miejsca, w którym mógłby się urodzić błąd zaokrąglenia. Zespół odzyskuje czas, który wcześniej szedł na odpisywanie na te same pytania.

Najważniejsze jest jednak to, że ten panel został naszym wzorcem. Rdzeń, na którym stoi - role, portfele, prowizje, zgłoszenia, i18n, tryb aplikacji - jest na tyle czysty, że dał się przenieść na kolejne marki bez przepisywania od zera. Zaczęliśmy od najtrudniejszego klienta, czyli siebie, i wyszła z tego architektura, którą potem tylko ubieraliśmy w kolejne barwy.