Studiu de caz

Migrarea codebase-ului unui SaaS multi-tenant de flota

O platforma SaaS de management de flota si dispecerat pentru firmele de transport din constructii, cele care muta agregate, pamant excavat si deseuri intre santiere. Am intrat ca inginer senior sa conduc migrarea codebase-ului, white-label printr-o agentie partenera: patru ani de lucru constant cu clientii dovedisera produsul. Ii trebuia o platforma care sa tina pasul.

Anonimizat sub NDA: produsul apare aici ca „Atlas Fleet”, iar tenantul afisat e fictiv.

Laravel 13 (PHP 8.4)Livewire 4Flux UIMySQLReact NativePestFCMNginxSupervisor

Problema

Sistemul pe care trebuia sa il inlocuiesc deservea douazeci de firme-client: munca reala, reglementata, cu exporturi Sage, preluare de la cantar, codificare EWC pentru deseuri si bonuri PDF cu proof-of-delivery. Nu era un prototip.

Ce il tragea inapoi era structural. Integrarea celui de-al douazeci si unulea client insemna inca un deploy, iar orice fix comun trebuia propagat de douazeci de ori. Designul care dusese produsul la douazeci de clienti il facea scump pe al douazeci si unulea. Fiecare client rula pe propria baza de date, propriul branch de git si propriul folder de asseturi compilate.

kestrel.atlasfleet.app · /login

[fig. 1] Loginul de tenant: fiecare client se autentifica pe propriul subdomeniu, iar pagina poarta culoarea acelui tenant. Brandingul e un rand in baza de date, nu un build separat per client.

Ce am construit

Migrarea codebase-ului pe Laravel 13 si PHP 8.4 s-a incheiat in mai putin de patru luni: o parte de birou pentru planificare si conformitate si o aplicatie de teren pentru soferi; fluxurile adunate de produs in patru ani au trecut intacte.

Schimbarea de fond e o singura baza de date comuna: fiecare inregistrare poarta un cont, fiecare tenant ramane in propriile date, iar subdomeniul stabileste cui apartine o cerere.

A ramas intentionat un monolit modular: o singura schema multi-tenant, queue workers sub Supervisor si acces pe rol pana la soferul pe token PIN.

Dashboard operational cu sase contoare, un rand de alerte rosii si galbene pentru conformitatea vehiculelor si un tabel cu transporturile recente. — [fig. 2] Verificarile de dimineata alimenteaza randul asta: un defect raportat de un sofer la 6 dimineata devine o alerta galbena in birou la 6:05.

Planificare pe saptamana, vehicul cu vehicul

Inima operationala a partii de birou e un grid de planificare saptamana-pe-vehicul.

Camioanele proprii apar dupa numar, subcontractorii dupa codul lor, iar cursele fara vehicul alocat stau intr-un rand galben, langa verificarile zilnice de siguranta, ale caror defecte urca in dashboardul de mai sus.

Ecran de planificare cu un grid saptamana-pe-vehicul: numere de inmatriculare si coduri de subcontractori in stanga, coloane pe zile cu etichete de curse si un rand galben pentru cele nealocate. — [fig. 3] Planificarea. Gridul saptamana × vehicul: flota proprie dupa numar, subcontractorii dupa hub code, etichete pe tip de transport (PD, MA, CO, CF) si randul galben „fara vehicul alocat”.

Ce folosesc soferii

O aplicatie React Native, in care soferii subcontractorilor intra pe un token PIN, fara cont. Soferul porneste un transport alegand cat de plin e camionul si il inchide cu un numar de bon, o poza si o semnatura; vede si cate tone mai sunt de mutat pe proiect.

Te gandesti la o migrare de codebase? Primul pas e parerea unui inginer senior despre versiunea pe care o ai acum. Pret fix, 1–3 zile, raport scris care ramane la tine.

Incepe cu un audit

Doua ecrane de telefon ale aplicatiei soferului: unul cu totaluri de tonaj pe proiect si butoane pentru gradul de incarcare, celalalt cu camp de bon, buton de poza, semnatura si buton de finalizare a transportului. — [fig. 4] Doua ecrane inseamna toata aplicatia soferului: porneste dupa gradul de incarcare, se inchide cu bon, poza si semnatura. Restul se intampla la birou.

Ce s-a schimbat

O baza de date, nu una per client: scoping pe cont intr-o singura schema, in loc de douazeci de conexiuni separate.
Un singur branch, nu unul per client: gata cu propagatul fiecarui fix comun prin douazeci de branch-uri.
Onboarding: de la un deploy la un rand de date: un server, un certificat, o baza de date, un branch.

Ai un codebase de migrat?

Spune-mi ce scartaie si cat de mare a crescut. Uneori raspunsul e o migrare completa; adesea e un singur blocaj pe care il scoti fara ea.

Rezerva un apel gratuit Incepe o discutie

Sau scrie-mi direct: office@ecdevlabs.com