Dokumentacja techniczna platformy SupportME

Jedna aplikacja Laravel obsługuje kilka niezależnych serwisów. To, który moduł i która baza danych obsłużą żądanie, zależy od hostu (domeny). Rozstrzyga to middleware ResolveTenant, uruchamiany jako pierwszy — przed sesją i tokenem CSRF — bo musi ustawić bazę i kontekst zanim cokolwiek innego się wykona.

Płatności obsługuje osobny moduł Gateway (własna baza nfc_pay), z którym sklepy komunikują się przez REST API i webhooki. Sklep nigdy nie rozmawia bezpośrednio z PayU — robi to bramka, co pozwala obsłużyć wiele sklepów jednym, bezpiecznym połączeniem z operatorem. Pełny cykl jest wielowarstwowy: webhook + aktywny polling + podpisy kryptograficzne.

Strona główna serwisu. Wyświetla produkty oznaczone tagami NFC (Serduszko, Kubek, Koszulka, Pin, Brelok). Każdy produkt ma własną minimalną kwotę. Domyślny produkt („Serduszko”, min. 1 zł) otwiera się automatycznie w modalu po wejściu. Kwota jest edytowalna w modalu, a walidacja minimum działa zarówno w przeglądarce, jak i na serwerze. Obsługiwane przez CompanyStoreController.

Główna funkcja platformy. Darczyńca zbliża telefon do znacznika NFC w kościele, trafia na stronę parafii, wybiera kwotę i płaci, a na końcu widzi ekran „Bóg zapłać”. Wszystkim steruje StorefrontController; dane parafii zarządzane są w panelu (sekcja 16). Każdy etap loguje zdarzenie do analityki.

Landing „Technologia, która pomaga czynić dobro” — zbudowany pixel-perfect z makiet Figmy (desktop i mobile). Sekcje są dynamiczne: kategorie „Kogo wspieramy?” pobierane są z bazy i zarządzane z panelu.

Statyczna strona marketingowa (GET /inwestorzy, nazwa trasy investors) zbudowana 1:1 z makiety Figmy. Hero „Inwestorzy i akcjonariusze”, sekcja misji kapitałowej („Wierzymy, że kapitał może służyć dobru”) oraz karty akcjonariuszy z kwotami inwestycji (kapitałowa + wsparcie usługowe). Renderowana bez kontrolera (Route::view).

Pełny system rekrutacyjny: publiczna lista ofert (zarządzana z panelu), strony ofert, formularz aplikacji z uploadem CV oraz powiadomienie e-mail z załączonym CV. Obsługiwany przez CareersController. CV trafia na prywatny dysk (niedostępny publicznie), a pobrać je można tylko z panelu.

Publiczny formularz kontaktowy (ContactController). Wiadomości zapisywane są do bazy i trafiają do skrzynki w panelu z licznikiem nieprzeczytanych. Temat może być wstępnie wypełniony z linku z oferty pracy (?stanowisko=…).

Statyczny dokument prawny (GET /regulamin, nazwa regulamin) — kompletny regulamin sklepu internetowego przeniesiony 1:1 z dokumentu źródłowego. 12 paragrafów + wzór formularza odstąpienia.

Po powrocie z bramki OrderReturnController synchronizuje status zamówienia i pokazuje właściwy ekran: sukces („Bóg zapłać”), oczekiwanie (z pollingiem) lub niepowodzenie (z opcją ponowienia). To zabezpiecza przed sytuacją, gdy klient wróci wcześniej niż dotrze webhook.

Sklep komunikuje się z bramką przez serwis GatewayClient oraz odbiera powiadomienia zwrotne (webhooki) o opłaceniu. Zdarzenia analityczne (np. tag_open) wysyłane są asynchronicznie, by nie spowalniać odpowiedzi.

Po co ten moduł i na co uważać

Klient bramki to jedyny punkt styku sklepu z warstwą płatności. Kluczowa zasada bezpieczeństwa: sklep nigdy nie ufa przekierowaniu z PayU ani redirectowi powrotnemu — status zamówienia ustala wyłącznie po zweryfikowanym webhooku lub po aktywnym odpytaniu API bramki (getTransaction). Dzięki temu nawet jeśli klient zamknie kartę zanim wróci na stronę, opłacone zamówienie i tak zostanie domknięte powiadomieniem.

Na co uważać: webhook wychodzący z bramki jest podpisany HMAC-SHA256 kluczem API sklepu — odrzuć każde żądanie z niepoprawnym lub brakującym podpisem (ryzyko podszycia i sztucznego oznaczania zamówień jako opłacone). Eventy analityczne (tag_open) wysyłamy po odesłaniu odpowiedzi (dispatchAfterResponse), aby nie wydłużać czasu odpowiedzi widzianego przez użytkownika.

// POST /api/v1/transactions — walidacja po stronie bramki (kontrakt dla klienta sklepu)
$data = $request->validate([
    'product_external_id' => ['required', 'string', 'max:255'],
    'product_name'        => ['required', 'string', 'max:255'],
    'amount'              => ['required', 'integer', 'min:1'], // grosze
    'currency'            => ['nullable', 'string', 'in:PLN'],
    'return_url'          => ['required', 'url', 'max:500'],
    'notify_url'          => ['nullable', 'url', 'max:500'],
    'tag_uid'             => ['nullable', 'string', 'max:255'],
]);
// odpowiedź: { "uuid": "...", "payment_url": "https://pay.../pay/{uuid}" }

Dlaczego to ważne: amount jest w groszach (liczba całkowita) — przesłanie „10.00” zamiast „1000” to najczęstszy błąd integracji. currency jest twardo ograniczone do PLN, a return_url musi być realnym URL-em (walidacja url), bo to na niego klient wróci po płatności.

Pola webhooka przychodzącego do sklepu

Samodzielna bramka płatnicza działająca jako odrębna aplikacja (pay.please-support-me.com, baza nfc_pay). Integruje PayU, obsługuje wiele sklepów, tagi NFC, transakcje, zdarzenia i statystyki. Zawiera 15 kontrolerów, własne API, panel oraz warstwę dostawców płatności (provider).

Dlaczego osobna bramka i na co uważać

Bramka jest celowo wydzielona jako odrębny tenant z własną bazą nfc_pay i dedykowanym połączeniem Eloquent (protected $connection = 'gateway' w każdym modelu). Dzięki temu dane finansowe są fizycznie odseparowane od danych sklepów, a jedne dane uwierzytelniające PayU obsługują wszystkie sklepy. Token OAuth jest cache'owany (payu_access_token, TTL ~12 h z marginesem 5 min), więc nie autoryzujemy się przy każdej transakcji.

Na co uważać: PayU zwraca utworzenie zamówienia jako HTTP 302 z JSON-em w body — dlatego klient HTTP ma wyłączone podążanie za przekierowaniem (allow_redirects => false). Status sukcesu to nie tylko SUCCESS, ale też WARNING_CONTINUE_3DS i WARNING_CONTINUE_REDIRECT (karty/3DS). Pominięcie tych dwóch zerwałoby płatności kartą.

// PayU REST v2.1 — POST /api/v2_1/orders (Http z allow_redirects=false)
$payload = [
    'merchantPosId' => (string) config('payment.payu.pos_id'),
    'extOrderId'    => $transaction->id,            // UUID = klucz idempotencji
    'customerIp'    => $customerIp ?: '127.0.0.1',
    'description'   => $transaction->product_name,
    'currencyCode'  => $transaction->currency,
    'totalAmount'   => (string) $transaction->amount, // grosze!
    'continueUrl'   => route('pay.return', $transaction->id),
    'notifyUrl'     => route('webhooks.payu'),
    'products' => [['name' => $transaction->product_name,
                    'unitPrice' => (string) $transaction->amount, 'quantity' => '1']],
];
// PayU oddaje 302 z JSON w body — NIE podążamy za redirectem
$statusCode = $data['status']['statusCode'] ?? null;
if (! in_array($statusCode, ['SUCCESS','WARNING_CONTINUE_3DS','WARNING_CONTINUE_REDIRECT'])
    || empty($data['redirectUri'])) { /* log + throw */ }

Dlaczego to ważne: extOrderId = UUID transakcji bramki, więc PayU nie utworzy dwóch zamówień dla tej samej transakcji (idempotencja). totalAmount w groszach jako string — typowy błąd to przeliczenie na złotówki.

Pola transakcji i mapowanie na bazę (Transaction → transactions)

Bramka udostępnia REST API dla sklepów (autoryzacja kluczem) oraz endpointy płatności i webhooki. Wszystkie powiadomienia są podpisywane i weryfikowane kryptograficznie.

Webhooki i podpisy — dlaczego to fundament

Cała pewność, że wpłata faktycznie nastąpiła, opiera się na weryfikacji podpisu. Webhook PayU niesie nagłówek OpenPayu-Signature w formacie sender=...;signature=...;algorithm=MD5;content=DOCUMENT. Podpis liczymy jako hash(body + second_key) wskazanym algorytmem i porównujemy hash_equals (porównanie odporne na timing attack). Po poprawnej weryfikacji bramka zawsze odpowiada 200 — w przeciwnym razie PayU ponawia powiadomienie.

Na co uważać: nie polegamy wyłącznie na webhooku. Endpoint statusu (GET /api/v1/transactions/{uuid}) przy każdym odpytaniu robi aktywną rekonsyliację z PayU (reconcileWithProvider) — gdy webhook się spóźni, status i tak zostanie domknięty. Statusy PayU mapujemy zachowawczo: tylko COMPLETED → opłacone, CANCELED → nieudane, reszta (PENDING, WAITING_FOR_CONFIRMATION) jest ignorowana.

// OpenPayu-Signature: "sender=...;signature=...;algorithm=MD5;content=DOCUMENT"
$signature = strtolower($parts['signature'] ?? '');
$algorithm = strtoupper($parts['algorithm'] ?? 'MD5');
$expected = match ($algorithm) {
    'MD5'               => md5($body . $secondKey),
    'SHA-256','SHA256'  => hash('sha256', $body . $secondKey),
    'SHA-1','SHA1'      => sha1($body . $secondKey),
    default              => null,
};
return $expected !== null && hash_equals($expected, $signature); // odporne na timing

// mapowanie statusu PayU → wewnętrzny (zachowawczo)
$status = match ($payuStatus) {
    'COMPLETED' => WebhookResult::STATUS_PAID,
    'CANCELED'  => WebhookResult::STATUS_FAILED,
    default     => WebhookResult::STATUS_IGNORED, // PENDING, WAITING_FOR_CONFIRMATION...
};

Dlaczego to ważne: hash_equals zamiast == chroni przed atakiem czasowym na porównanie podpisu. Brak second_key lub pustego nagłówka = natychmiastowe odrzucenie (return false).

Pola żądań API i mapowanie na bazę

Pełna mapa tras płatności (z PaymentController)

Panel bramki (osobne logowanie) służy do zarządzania sklepami, tagami NFC, statystykami i leadami. Zawiera też moduły demonstracyjne (anti-theft, tryb testowy płatności).

Pola formularza sklepu i mapowanie na bazę (Shop → shops)

// 64 znaki hex = 256 bitów entropii
public static function generateApiKey(): string
{
    return bin2hex(random_bytes(32));
}
// klucz nigdy nie wycieka do JSON/odpowiedzi:
protected $hidden = ['api_key'];
// modele bramki zawsze czytają z bazy nfc_pay, niezależnie od tenanta hosta:
protected $connection = 'gateway';

Dlaczego to ważne: random_bytes to kryptograficznie bezpieczny generator (nie rand), a $hidden gwarantuje, że klucz nie pojawi się przypadkiem w żadnej odpowiedzi API. Stałe połączenie gateway izoluje dane finansowe od bazy aktywnego sklepu.

Pola taga NFC i leada (Tag → tags, Lead → leads)

Moduł Anti-theft (AntitheftCheck → antitheft_checks: shop_id, status ok/warning, foreign_tags_found, checked_at) jest oznaczony w kodzie komentarzem // FIKCYJNE — moduł demo, brak realnej detekcji i zawsze zwraca foreign_tags_found = 0 — szkielet gotowy do rozbudowy.

Panel sklepu (/panel) chroniony jest logowaniem (middleware auth). Po zalogowaniu dashboard pokazuje kondycję sprzedaży. Łącznie panel udostępnia ponad 50 tras.

Pola formularza logowania i mapowanie na bazę

Na co uważać: błąd logowania zwraca celowo ogólny komunikat „Niepoprawny login lub hasło.” (nie zdradza, czy istnieje konto o danym e-mailu). Po sukcesie regenerujemy sesję (session()->regenerate()) — ochrona przed session fixation. Logowanie jest „remember me” na stałe (drugi argument Auth::attempt(..., true)).

$credentials = $request->validate([
    'email'    => ['required', 'email'],
    'password' => ['required'],
], [], ['email' => 'e-mail', 'password' => 'hasło']);

if (! Auth::attempt($credentials, true)) { // true = remember me
    return back()->withErrors(['email' => 'Niepoprawny login lub hasło.'])->onlyInput('email');
}
$request->session()->regenerate(); // anty session-fixation
return redirect()->intended(route('panel.dashboard'));

Dlaczego to ważne: ogólny komunikat błędu utrudnia enumerację kont, a regeneracja ID sesji po zalogowaniu zamyka klasę ataków na przejęcie sesji. Wylogowanie dodatkowo unieważnia sesję i regeneruje token CSRF.

Najbogatsza sekcja panelu (ProductController): pełny CRUD parafii wraz z galerią zdjęć, opisem WYSIWYG, statystykami oraz wbudowanym CRM (statusy leada, notatki, przypisany handlowiec). Publikacja parafii sterowana jest statusem — ustawienie „aktywna” włącza widoczność publiczną.

Pola formularza parafii i mapowanie na bazę

Reguły poniżej pochodzą wprost z ProductController::validated(). Cena wpisywana jest w złotych, a do bazy trafia w groszach. Status steruje publikacją: tylko aktywna ustawia active = true (parafia widoczna publicznie); pozostałe traktowane są jak lead (ukryta).

// cena wpisywana w złotówkach — w bazie trzymamy grosze
$data['price'] = (int) round(((float) str_replace(',', '.', (string) $data['price'])) * 100);
// status steruje publikacją: 'aktywna' => publiczna, pozostałe => lead (ukryta)
$data['active'] = $data['status'] === 'aktywna';
$data['salesperson_id'] = $data['salesperson_id'] ?: null;

Dlaczego to ważne: konwersja zł→grosze jest tu jedyna i spójna; obsługuje zarówno kropkę, jak i przecinek (PL). Sprzężenie active = (status === 'aktywna') oznacza, że nie da się opublikować parafii inaczej niż przez ustawienie statusu „aktywna” — to zapobiega publikacji niedokończonych leadów.

Pola notatki CRM i mapowanie (ParishNote → parish_notes)

Notatki dodawane są AJAX-em i zwracane jako JSON (bez przeładowania) wraz z etykietą typu i datą. Usunięcie notatki sprawdza, że należy ona do tej parafii (abort_unless($note->product_id === $product->id, 404)) — ochrona przed manipulacją ID.

Drzewo kategorii „Kogo wspieramy?” (CategoryController) sterujące sekcjami na stronie głównej. Obsługuje zagnieżdżanie (parent/child), zmianę kolejności i ikony, z ochroną przed cyklami.

Pola formularza kategorii i mapowanie na bazę

Reguły z CategoryController::validated(). label_text domyślnie przyjmuje wartość label, a label_html — escaped label_text; slug generowany jest z nazwy, gdy puste, i uspójniany do unikalności iteracyjnie.

// z listy możliwych rodziców wykluczamy edytowaną kategorię i WSZYSTKICH jej potomków
$excluded = $current ? $this->descendantIds($all, $current->id) : [];
foreach ($all->where('parent_id', $parentId) as $cat) {
    if (in_array($cat->id, $excluded, true)) { continue; } // blokada cyklu
    $options[$cat->id] = str_repeat('— ', $depth) . $cat->label_text;
}
// usunięcie rodzica NIE kasuje dzieci — FK nullOnDelete czyni je top-level

Dlaczego to ważne: rekurencyjne descendantIds zbiera całe poddrzewo, więc select rodzica nigdy nie zaproponuje opcji tworzącej cykl. Usunięcie kategorii dzięki nullOnDelete przenosi dzieci na poziom wyższy zamiast je kasować.

CRUD handlowców (SalespersonController) z przypisaniem obsługiwanych województw i licznikiem przypisanych parafii. Integruje się z CRM parafii i mapą pokrycia.

Pola formularza handlowca i mapowanie na bazę

Reguły z SalespersonController::validated(). Lista województw jest słownikiem zamkniętym (stała Salesperson::VOIVODESHIPS, 16 pozycji RP) — każde wybrane województwo musi do niej należeć.

// walidacja: każde województwo musi należeć do zamkniętego słownika
'voivodeships'   => ['nullable', 'array'],
'voivodeships.*' => ['string', 'in:' . implode(',', Salesperson::VOIVODESHIPS)],
// pusta lista => null (kolumna nullable); tablica => cast 'array' w modelu => JSON
$data['voivodeships'] = ! empty($data['voivodeships']) ? array_values($data['voivodeships']) : null;

Dlaczego to ważne: zamknięty słownik (in:) blokuje literówki i „lewe” województwa, dzięki czemu filtr mapy pokrycia i przypisania CRM zawsze działają na spójnych wartościach. Cast 'array' w modelu serializuje listę do JSON i deserializuje z powrotem bez ręcznego json_encode.

Lista leadów parafialnych (PotentialParishController) zaimportowanych z OpenStreetMap, z lejkiem obdzwaniania i interaktywną mapą pokrycia (Leaflet). Filtry: województwo, status, handlowiec, obecność telefonu. Paginacja po 50.

Pola aktualizacji leada i mapowanie na bazę

Reguły z PotentialParishController::updateStatus(). Dataset (~20 tys. parafii) pochodzi z OpenStreetMap (import parishes:import); telefon i adres uzupełniane są później (parishes:enrich / inline w panelu), bo OSM ich nie zawiera.

// stempel pierwszego kontaktu — ustawiany RAZ, przy przejściu do „zadzwoniono”
if ($data['status'] === 'zadzwoniono' && $potentialParish->called_at === null) {
    $potentialParish->called_at = now();
}
// filtr telefonu: domyślnie 'with' (pokazujemy TYLKO parafie z numerem)
$hasPhone = $request->query('has_phone', 'with');
if ($hasPhone === 'with') {
    $query->whereNotNull('phone')->where('phone', '!=', '');
}

Dlaczego to ważne: warunek called_at === null gwarantuje, że data pierwszego telefonu nie jest nadpisywana przy kolejnych zmianach statusu. Domyślny filtr with chroni handlowca przed listą 20 tys. rekordów bez numerów — od razu widzi to, co można obdzwonić.

Mapa pokrycia (coverageData) — transfer danych

Endpoint GET /panel/coverage ładuje markery AJAX-em (NIE wkleja 20 tys. punktów do HTML). coverageData() zwraca tylko niezbędne kolumny (id, name, city, voivodeship, lat, lon, phone, status, salesperson_id, note) plus kolor wg statusu — oszczędność transferu i czasu renderu. Filtry mapy są te same co listy, więc markery można zawężać re-fetchem.

CRUD produktów sklepu donacyjnego (ShopItemController): minimalna kwota, tag NFC, produkt domyślny (tylko jeden), upload grafiki, kolejność i aktywność. Cena wpisywana w złotych, zapisywana w groszach.

Pola formularza produktu NFC i mapowanie na bazę

Reguły z ShopItemController::validated(). Kwota minimalna wpisywana jest w złotych (min_amount_pln) i przeliczana na grosze. Slug generowany ze slugu lub z nazwy; grafika trafia na dysk public, a ścieżka zapisywana z prefiksem storage/.

// zł → grosze (kwota minimalna)
'min_amount' => (int) $data['min_amount_pln'] * 100,

// tylko JEDEN produkt może być domyślny — zdejmij flagę z pozostałych
if ($request->boolean('is_default')) {
    ShopItem::where('id', '!=', $item->id)->update(['is_default' => false]);
    $item->update(['is_default' => true]);
}

Dlaczego to ważne: produkt domyślny („Serduszko”) pokazuje się w modalu po wejściu na stronę sklepu — gdyby dwa były domyślne, modal byłby niejednoznaczny. applyDefault atomowo zdejmuje flagę ze wszystkich innych przed ustawieniem nowego domyślnego.

CRUD ofert pracy (PositionController) z opisem WYSIWYG, lokalizacją, typem zatrudnienia, kolejnością i licznikiem aplikacji per oferta. Oferty pojawiają się publicznie na /praca.

Pola formularza stanowiska i mapowanie na bazę

Reguły z PositionController::validated(). Oferty z active = true pojawiają się publicznie na /praca; sort ustala kolejność wyświetlania.

Na co uważać: usunięcie stanowiska nie kasuje powiązanych zgłoszeń — FK job_applications.job_position_id ma nullOnDelete, więc aplikacje stają się „spontaniczne” (bez oferty), zamiast zniknąć. Lista stanowisk pokazuje licznik aplikacji per oferta (withCount('applications')).

Skrzynka zgłoszeń rekrutacyjnych (ApplicationController) z pobieraniem CV z prywatnego dysku, statusami i filtrami. Licznik nieprzeczytanych widoczny w nawigacji panelu.

Pola zgłoszenia rekrutacyjnego i mapowanie na bazę

Zgłoszenia trafiają z publicznego formularza /praca; panel służy do ich przeglądania, zmiany statusu i pobrania CV. job_position_id = NULL oznacza aplikację spontaniczną (bez konkretnej oferty).

// CV na dysku 'local' (NIE public) — niedostępne z URL-a; tylko przez panel
abort_unless($application->cv_path && Storage::disk('local')->exists($application->cv_path), 404);
return Storage::disk('local')->download(
    $application->cv_path,
    $application->cv_original_name ?: basename($application->cv_path)
);
// usunięcie zgłoszenia kasuje też plik CV (sprzątanie dysku)

Dlaczego to ważne: CV zawiera dane osobowe — przechowywanie na dysku local (poza public/) oznacza, że nie da się go pobrać bez przejścia przez kontroler chroniony logowaniem. Walidacja exists chroni przed 500 przy zgubionym pliku.

Skrzynka wiadomości z formularza kontaktowego (MessageController) z licznikiem nieprzeczytanych.

Pola wiadomości kontaktowej i mapowanie na bazę

Wiadomości pochodzą z publicznego formularza kontaktowego; panel jest skrzynką odbiorczą (najnowsze na górze, licznik nieprzeczytanych w nawigacji). Otwarcie wiadomości oznacza ją jako przeczytaną.

Na co uważać: model ma public $timestamps = false i własne created_at z DB default (useCurrent()) — nie ma kolumny updated_at. Oznaczenie jako przeczytane to jedyna mutacja rekordu w panelu (poza usunięciem).

System rejestruje każde istotne zdarzenie — od zbliżenia telefonu po finalną wpłatę — co zasila statystyki w panelu i pozwala mierzyć konwersję. Zdarzenia trzymane są w tabeli events (z indeksem po typie i dacie), a agregacją zajmuje się ShopStatsService.

Dwie tabele events — sklep vs bramka

W systemie istnieją dwie odrębne tabele events (po jednej w bazie sklepu i w bazie bramki), o różnych zestawach typów. To celowe: sklep mierzy lejek sprzedażowy parafii/produktu, a bramka — lejek płatności. Obie mają indeksy po typie i dacie, by agregacje były szybkie.

// POST /api/v1/events — sklep autoryzowany middleware (X-Api-Key → $shop)
$data = $request->validate([
    'type'    => ['required', 'in:tag_open'],
    'tag_uid' => ['nullable', 'string', 'max:255'],
]);
// tag szukany TYLKO w obrębie sklepu, który raportuje (izolacja tenantów)
$tag = Tag::where('shop_id', $shop->id)->where('tag_uid', $data['tag_uid'])->first();
Event::create(['shop_id' => $shop->id, 'tag_id' => $tag?->id, 'type' => $data['type']]);

Dlaczego to ważne: dowiązanie taga warunkowane shop_id uniemożliwia jednemu sklepowi zaraportowanie eventu na tag innego sklepu (izolacja danych w multi-tenant). tag?->id pozwala zapisać event nawet bez znanego taga.

Metryki dashboardu (ShopStatsService)

18 migracji budujących ~25 tabel w trzech bazach (multi-tenant). Poniżej wszystkie tabele z kluczowymi kolumnami.

Pełne typy kolumn z migracji — bramka (nfc_pay)

Pełne typy kolumn z migracji — sklep (nfc_shop1)

Mapa kluczy obcych i zachowań kasowania

// każdy model bramki:
protected $connection = 'gateway'; // zawsze nfc_pay, nawet gdy host = sklep
// połączenie 'mysql' jest podmieniane per host w ResolveTenant:
config(['database.connections.mysql.database' => $tenant['database']]);

Lekki, nowoczesny stos oparty o Laravel 12 — bez ciężkiego frontendu SPA, co przekłada się na szybkość i prostotę utrzymania.

Dokument wygenerowany automatycznie na podstawie analizy kodu źródłowego. Moduły oznaczone „Aktywny” działają na produkcji please-support-me.com; „Demo” są zbudowane i działają w trybie pokazowym/testowym.