ix
ix

informatix

EN version Porozmawiajmy o projekcie
Strona główna / Blog / Case study: architektura OneCRMApp — Laravel 12, React i Ine...
• 4 min czytania •

Case study: architektura OneCRMApp — Laravel 12, React i Inertia [2026]

Jak budujemy i utrzymujemy OneCRMApp, CRM dla agentów ubezpieczeniowych: dlaczego Inertia.js zamiast API od pierwszego dnia, model EAV dla polis, tuning PostgreSQL i lekcje z produkcyjnego SaaS.

Większość artykułów o architekturze opisuje stack hipotetyczny. Ten opisuje produkt, który codziennie działa produkcyjnie: OneCRMApp, CRM dla agentów ubezpieczeniowych, zbudowany na Laravel 12, React i Inertia.js. To praktyczna odpowiedź na pytanie, które zadają pozostałe artykuły tego klastra — tak wyglądają decyzje, gdy od nich zależą prawdziwi użytkownicy.

Problem i produkt

Agenci ubezpieczeniowi w Polsce pracują na arkuszach, notatkach i kilku portalach towarzystw. Polisy są rozrzucone, terminy odnowień uciekają, a szanse na dosprzedaż przepadają. OneCRMApp zbiera klientów, polisy, przypomnienia i prowizje w jednym miejscu — w webie i na telefonie.

To ukształtowało pierwsze wymaganie architektoniczne: jeden zespół, jedno repozytorium, szybka iteracja. Bez osobnej drużyny frontendowej, bez ceremonii API-first.

Dlaczego Inertia.js, a nie API + SPA

W momencie startu jedynym klientem była aplikacja webowa. Budowa REST API na początek oznaczałaby projektowanie i wersjonowanie kontraktu z jednym konsumentem — koszt bez klienta. Inertia.js dała doświadczenie SPA w React z routingiem, sesjami i walidacją Laravela nienaruszonymi — dokładnie tak, jak opisujemy w Inertia.js z Laravel i React.

Gdy roadmapa dodała integracje i klienta mobilnego, wyciągnęliśmy endpointy REST za Sanctum — z ponownym użyciem tych samych kontrolerów, FormRequestów i polityk. Ekstrakcja zajęła dni, bo szwy były zaprojektowane pod nią; uzasadnienie znajdziesz w Sanctum SPA czy sesje Inertia.

  • ## Trudny problem danych: polisy, z których każda jest inna

Każdy produkt ubezpieczeniowy ma własne pola i warunki. Modelowanie każdego jako kolumny rozsadza schemat; trzymanie wszystkiego w JSON zabija wydajność zapytań. Używamy hybrydy:

  • Pola stabilne (klient, towarzystwo, składka, daty, status) to zwykłe indeksowane kolumny — filtry i raporty zostają szybkie.
  • Pola specyficzne dla produktu żyją w warstwie EAV opartej o JSONB w PostgreSQL z indeksami GIN.
  • Obliczenia odnowień działają jako zadania w tle i zmaterializowane podsumowania, więc dashboardy nigdy nie skanują surowych polis.

PostgreSQL tu zarabia na siebie — indeksy częściowe, zapytania zawierania JSONB i funkcje okna zastąpiły warstwę raportową, którą inaczej trzeba by pisać w aplikacji.

Decyzje wydajnościowe, które zostały

  • Deferred props na dashboardzie: liczniki i listy malują się od razu, wykresy docierają drugą falą — patrz Inertia.js v2 — nowości.
  • Kolejkuj wszystko wolne: wywołania API towarzystw, eksporty, e-maile przypominające — Horizon.
  • Redis na cache i kolejki; PostgreSQL strojony pod wzorce zapytań, nie pod folklor.
  • SSR na stronach publicznych — marketing i rejestracja — a aplikacja za logowaniem zostaje renderowana po stronie klienta: podział, który rekomendujemy w Inertia.js SSR w Laravel.

Najważniejsze: Zakład architektoniczny, który zwrócił się najbardziej, to odroczenie API. Dostarczyliśmy produkt miesiące wcześniej, a gdy pojawił się drugi klient, nic nie trzeba było przepisywać — tylko wyciągnąć.

Rezultaty i co dalej

Agenci korzystający z OneCRMApp oszczędzają około 5 godzin tygodniowo na administracji, a przypomnienia o odnowieniach podniosły sprzedaż renewals o około 20% w pierwszych grupach. Produkt jest aktywnie rozwijany — klient mobilny i integracje z towarzystwami to bieżąca roadmapa, oba na wyciągniętym API.

Jeśli budujesz produkt w niszy, w której gotowe narzędzia są za ogólne i za ciężkie, to kształt, który rekomendujemy: skupiony model domeny, jedno repozytorium, Inertia do interfejsu i API dodawane wtedy, gdy drugi klient na to zapracuje. Robimy tak również dla klientów — zobacz tworzenie aplikacji Laravel.

FAQ

Dlaczego Inertia.js, a nie API-first?

W momencie startu web był jedynym klientem — Inertia pozwoliła uniknąć kontraktu API dla jednego konsumenta. Endpointy wyciągnęliśmy później, z ponownym użyciem kontrolerów i polityk.

Jak modelujecie różne typy polis?

  • Hybrydowo: stabilne pola jako indeksowane kolumny, pola produktowe w warstwie EAV nad JSONB w PostgreSQL z indeksami GIN.

Czy OneCRMApp jest dostępny dla nowych użytkowników?

Tak — rejestracja jest otwarta na onecrmapp.com, a produkt aktywnie się rozwija wraz z feedbackiem użytkowników.

👉 Budujesz niszowy SaaS albo CRM? Zobacz, jak do tego podchodzimy w usłudze tworzenia aplikacji Laravel, albo sprawdź sam produkt: OneCRMApp.

📖 Czytaj dalej: Inertia.js z Laravel i React, Inertia.js SSR w Laravel i Sanctum SPA czy sesje Inertia.

Powiązane wpisy

20.10.2026

Laravel Sanctum SPA czy sesje Inertia.js [2026]

Dwa sposoby uwierzytelnienia frontendu React w Laravelu: Sanctum z tokenami API dla osobnego SPA albo sesje Inertia.js w jednej aplikacji. Jak działają, ile kosztują i kiedy przejść między nimi.

Czytaj dalej