Produse SaaS B2B. De la idee la production-ready.

Blocaje pe care le eliminăm

• Capcana MVP-ului de o săptămână

  Sisteme livrate într-o săptămână cu no-code sau monolit fragil. Funcționează pe demo. La primii 100 useri activi, DB-ul cade sub joins ne-indexate, queue-urile blochează request-urile și billing-ul greșește abonamentele. Rezultat: rescriere completă de la zero. MVP-ul "rapid" devine cel mai scump POC din portofoliul tău.

• Coșmarul scurgerilor de date / Multi-Tenancy

  Baze de date proiectate fără Row Level Security. Un bug în WHERE clause sau un join greșit într-un endpoint, și clientul A vede datele clientului B. Apare o singură dată — și e suficient să pierzi contractul + reputația + să raportezi la DPA. Multi-tenancy nu se rezolvă cu "grijă în query-uri". Se rezolvă cu RLS la nivel de DB.

• Desincronizarea facturării

  Stripe trimite webhooks. Webhooks pot ajunge de două ori, în afara ordinii sau deloc dacă endpoint-ul tău returnează 500. Fără idempotență, ajungi cu useri Premium fără plată sau utilizatori blocați care au plătit. Suport client epuizat și un MRR raportat greșit la investitori — direct din webhook handler.

Arhitectura. Stack-ul. Compromisurile.

• Date & izolare

  Fiecare tabelă cu date de tenant are politică RLS pe tenant_id, activată în migrare, nu în cod de aplicație. Sesiunea de DB primește tenantul din token la începutul request-ului, deci un endpoint scris greșit returnează zero rânduri, nu rândurile altcuiva. Migrările sunt versionate și rulate în CI înainte de deploy, cu rollback testat.

  • PostgreSQL
  • Row Level Security
  • Migrări versionate

• Billing & evenimente

  Webhook-urile Stripe intră într-o tabelă de evenimente cu constrângere unică pe event ID, apoi sunt procesate într-o tranzacție. Retrimiterea aceluiași eveniment nu produce a doua schimbare de abonament. Semnătura e verificată înainte de orice citire a payload-ului, iar un eveniment care eșuează rămâne în coadă cu retry, nu dispare într-un catch tăcut.

  • Stripe
  • Webhooks
  • Idempotency keys

• Livrare & observabilitate

  Fiecare pull request primește un mediu de preview cu date de test, cu lint, typecheck și suita de teste ca gate de merge. În producție, logging structurat cu request ID propagat prin toate straturile și alerting pe rata de eroare, nu pe volumul de log. Când billing-ul sau autentificarea cedează, afli din alertă, nu din tichetul unui client.

  • CI/CD
  • Preview deployments
  • Structured logging

Cum lucrez

1. 01

   Data Isolation & Security (PostgreSQL)

   Row Level Security nativ pe PostgreSQL — fiecare query e automat filtrat după tenant_id la nivel de motor de DB, nu la nivel de aplicație. Imposibil ca un dezvoltator să livreze accidental un endpoint care leak-uiește date între tenanți. Plus audit log pe toate scrierile, criptare at-rest pe coloane sensibile, backup-uri verificate la restore. Multi-tenancy ca arhitectură, nu ca aspirație.

2. 02

   Backend & Idempotent Billing (Node.js / Laravel)

   API-uri scrise cu contracte explicite (OpenAPI schema validată la build). Integrare Stripe via webhooks idempotente — fiecare event are signature verification + idempotency key, procesare în transaction, deduplicare pe event ID. Upgrade-uri, downgrade-uri, dunning, proration, refund — toate fail-safe. Plătit înseamnă acces; neplătit înseamnă grace period documentat, nu suspendare aleatoare.

3. 03

   Frontend Decuplat (Next.js / React)

   Single Page Application pe Next.js cu React Query sau SWR pentru data fetching. Optimistic UI, revalidare asincronă, zero page reloads chiar pe operații heavy. State management complex tipizat (Zustand / Redux Toolkit). Dashboards care livrează 60fps pe tabele de 10.000 rânduri prin virtualizare — operatorii lucrează, nu așteaptă spinner-uri.

Întrebări frecvente

• Cât durează lansarea unui MVP în producție?+

  Între 6 și 12 săptămâni, în funcție de complexitatea logicii de business. Nu facem hack-uri ca să livrăm în 2 săptămâni — timpul investit construiește fundația tehnică pe care scalezi în următorii 3 ani fără rescrieri. Alternativa "rapid și ieftin" îți va costa de 5x mai mult la primul milestone.
• Codul îmi aparține? Rămân dependent de voi?+

  Zero vendor lock-in. Repository GitHub pe organizația ta din ziua 1. Infrastructura Vercel sau AWS pe contul tău, cu credențiale care îți rămân. Documentație tehnică, runbook-uri operaționale, schema migrată cu istoric versionat. Poți migra la altă echipă mâine, fără asistența noastră — și asta e o trăsătură, nu un bug.
• Cum gestionați rolurile utilizatorilor (Admin, Editor, Viewer)?+

  RBAC dual. Vizibilitate verificată în interfața React (un Viewer nu vede butonul Delete) ȘI permisiuni enforced strict la nivel de middleware pe fiecare request API — chiar dacă un atacator face curl direct la endpoint, primește 403. Frontend-ul ascunde; backend-ul refuză. Singura combinație care nu e exploatabilă.
• Ce se întâmplă dacă vrem să schimbăm procesatorul de plăți?+

  Logica de abonament nu apelează Stripe direct. Există un strat de billing cu propriile entități — plan, abonament, perioadă de grație, eveniment de plată — iar Stripe e doar un adaptor care traduce webhook-urile în aceste entități. Schimbarea procesatorului înseamnă un adaptor nou și o migrare de date, nu rescrierea aplicației. Același strat face testarea posibilă fără să lovești un API extern.
• Cum testați multi-tenancy și billing-ul înainte de lansare?+

  Teste de integrare pe o bază de date reală, cu doi tenanți seed-uiți: fiecare test care citește date rulează de două ori și verifică explicit că tenantul B nu vede nimic din A. Pentru billing rulăm webhook-uri Stripe înregistrate, inclusiv duplicate și în ordine inversă, ca să dovedim idempotența. Un test care trece doar pentru că baza de date e goală nu e un test.