Ce este SaaS: anatomia unei platforme software moderne

Termenul SaaS e lipit pe orice rulează în browser. Pentru un decident tehnic care vrea să construiască un produs, definiția asta nu spune nimic util. Ce contează e ce se află sub interfață: cum izolezi datele a sute de clienți pe același cod, cum încasezi recurent fără să atingi vreodată un card și ce cifre îți spun dacă produsul trăiește sau moare lent.

Ghidul ăsta descompune o platformă SaaS pe straturi — de la client până la baza de date — și pune pe masă deciziile de arhitectură pe care le iei o singură dată, dar le plătești ani de zile. E scris pentru CTO, founder sau tech lead care evaluează un build, nu pentru cineva care caută o definiție de dicționar.

SaaS vs software clasic: ce se schimbă de fapt

Cu software clasic vinzi o licență. Clientul instalează, rulează pe infrastructura lui, te cheamă când ceva se strică. Cu SaaS, clientul nu cumpără software — închiriază acces. Tu rulezi infrastructura, tu porți costul de hosting, securitate și update, iar el plătește recurent atâta timp cât îi aduci valoare.

Schimbarea asta de model are trei consecințe directe. O singură bază de cod servește toți clienții (de aici termenul multi-tenant). Venitul nu mai vine în tranșe mari și rare, ci ca flux recurent lunar — MRR, metrica în jurul căreia se învârte tot restul. Și relația nu se termină la vânzare: dacă produsul nu rămâne util luna viitoare, clientul pleacă, iar tu pierzi venit pe care îl considerai sigur.

Nu e un model de nișă. Peste 70% dintre furnizorii SaaS moderni rulează deja pe o formă de multi-tenancy, iar piața globală SaaS e estimată la circa 465 de miliarde de dolari în 2026, potrivit analizelor de piață din acest an. Deciziile de mai jos sunt teren bătătorit: există tipare clare, iar greșelile costisitoare sunt și ele bine documentate.

Anatomia unei platforme SaaS pe straturi

O cerere care intră într-un SaaS trece prin straturi bine definite. Fiecare strat rezolvă o problemă și o ascunde de cel de deasupra. Le poți construi prost individual și încă să ai un produs care merge — dar deciziile greșite la straturile de jos (multi-tenancy, date) se transformă în rescrieri de luni de zile.

Clientul e ce vede utilizatorul: browser, aplicație mobilă sau, tot mai des, alt sistem care îți consumă API-ul. Autentificarea și sesiunea verifică cine e și ce are voie să facă — login prin OAuth sau JWT, roluri, permisiuni. Până aici, lucrurile seamănă cu orice aplicație web.

Multi-tenancy e stratul care face dintr-o aplicație web un SaaS: aici stabilești cărui client îi aparțin datele și te asiguri că un tenant nu vede niciodată datele altuia. Aplicația și API-ul conțin logica de business propriu-zisă — și, dacă expui un API ca produs, partea de API-as-a-Service. Billing-ul transformă utilizarea în bani: planuri, facturare recurentă, recuperarea plăților eșuate. La bază stau datele, organizate astfel încât izolarea per tenant să fie garantată, nu doar sperată.

Următoarele două straturi — multi-tenancy și billing — sunt cele care diferențiază un SaaS de o aplicație obișnuită. Merită fiecare câte o secțiune.

Modele de multi-tenancy: cum izolezi datele clienților

Întrebarea centrală a oricărui SaaS: pe aceeași infrastructură, cum garantezi că datele clientului A nu ajung niciodată la clientul B? Răspunsul determină cât te costă să adaugi al 1.000-lea client și cât de greu îți e să treci un audit de securitate. Există trei modele.

În modelul pool (schemă comună), toți clienții împart aceleași tabele. Fiecare rând are o coloană tenant_id, iar izolarea se face prin Row-Level Security (RLS) — o politică la nivelul bazei de date care nu lasă o interogare să returneze rânduri ale altui tenant. E cel mai ieftin de operat și cel mai simplu de migrat: o singură schemă, o singură rută de migrare, un singur backup.

Riscul e tot atât de simplu: un WHERE tenant_id = ? uitat undeva în cod, și un client vede datele altuia. Nu e teoretic — a produs incidente reale de securitate. De aceea, în modelul pool, RLS la nivel de Postgres nu e opțional, ci ultima linie de apărare:

1ALTER TABLE proiecte ENABLE ROW LEVEL SECURITY;
2CREATE POLICY izolare_tenant ON proiecte
3  USING (tenant_id = current_setting('app.tenant_id')::uuid);

1ALTER TABLE proiecte ENABLE ROW LEVEL SECURITY;
2CREATE POLICY izolare_tenant ON proiecte
3  USING (tenant_id = current_setting('app.tenant_id')::uuid);

Chiar și RLS are limite. O vulnerabilitate PostgreSQL raportată la final de 2024 (CVE-2024-10976) a arătat că politicile RLS combinate cu connection pooling puteau, în anumite condiții, să scape rânduri ale altui tenant. Concluzia practică: izolarea nu se bazează niciodată pe un singur mecanism.

Celelalte două modele mută granița mai sus. Bridge (schemă per tenant) ține o singură bază, dar fiecare client primește schema lui — izolare mai bună, dar gestionezi sute de scheme și migrările devin mai grele. Silo (bază per tenant) dă fiecărui client baza lui de date: izolare fizică completă, cerută adesea în healthcare, financiar sau contracte enterprise mari — la cost și complexitate operațională maxime.

Tiparul recomandat de majoritatea echipelor: pornești în pool cu RLS pentru toți clienții și „promovezi" la silo doar clienții enterprise care cer izolare fizică prin contract. Migrarea în sens invers e scumpă — a trece de la schemă comună la bază-per-tenant după 500 de clienți e un proiect de rearhitecturare de 6–12 luni. Alege devreme, dar lasă-ți o cale de upgrade.

Billing și abonamente: cum încasezi recurent

Facturarea recurentă pare simplă până când intri în detalii: planuri lunare și anuale, proration la upgrade la mijloc de lună, taxe diferite per țară, și plăți eșuate care trebuie reîncercate automat (dunning) ca să nu pierzi venit din carduri expirate. Ai, în mare, două drumuri.

Procesator de plăți (ex. Stripe). Tu rămâi vânzătorul legal; procesatorul mută banii. Stripe percepe 2,9% + 0,30 USD pe tranzacție (standard SUA; în Europa baza e în jur de 1,5% + 0,25 EUR), plus un add-on Billing de 0,7% pe volumul de abonamente, potrivit grilei de prețuri Stripe pe 2026. Plățile internaționale adaugă circa 1,5%, iar conversia valutară încă 1%. Avantajul e controlul total și costul de bază mai mic; dezavantajul e că taxele rămân responsabilitatea ta (Stripe Tax calculează și colectează la 0,5%, dar declararea și plata către stat rămân la tine). Semn al direcției pieței: în ianuarie 2026, Stripe a cumpărat Metronome pentru circa 1 miliard de dolari, ca să acopere billing-ul pe consum, tot mai cerut de produsele AI.

Merchant of Record (ex. Paddle, FastSpring). Aici furnizorul devine vânzătorul legal: el apare pe extrasul clientului, el colectează și remite TVA-ul și taxele de vânzări în peste 200 de țări, tu primești suma netă. Paddle percepe 5% + 0,50 USD pe tranzacție, fără abonament, conform paginii sale de prețuri — rata efectivă ajunge des spre 7% când adaugi conversia valutară. Pare scump până compari cu costul real al conformității fiscale globale (un serviciu de tax compliance costă tipic câteva mii până la 20.000 USD pe an). MoR are sens când vinzi global și nu vrei să te înregistrezi la TVA în zeci de jurisdicții.

Un caz de urmărit în 2026: Lemon Squeezy, popular printre indie SaaS, e absorbit treptat în Stripe Managed Payments (noul produs MoR al Stripe, intrat în preview public în februarie 2026), care păstrează aceeași taxă de 5% + 0,50 USD. Dacă evaluezi azi, contează că Lemon Squeezy ca produs separat e pe drumul spre integrare în Stripe, nu un pariu independent pe termen lung. Alternative MoR mai noi există — de exemplu Creem la 3,9% + 0,40 USD — dar ecosistemul lor e mai mic.

Regula generală pe care o aplică multe echipe: pornești cu un MoR pentru simplitate (taxe rezolvate, integrare în zile) și treci la un procesator când volumul justifică economia și ai resurse de finanțe interne. Pragul de trecere e tipic undeva la 50.000–100.000 USD venit recurent lunar. Dacă produsul tău expune un API ca ofertă comercială, billing-ul pe consum și gestionarea cheilor API devin parte din produs, nu un detaliu de infrastructură.

Metricile care decid dacă SaaS-ul tău trăiește

Un SaaS nu se evaluează ca un business clasic. Câteva metrici îți spun, lună de lună, dacă crești sănătos sau torni apă într-o găleată spartă.

MRR și ARR (venitul recurent lunar și anual) sunt pulsul. Dar numărul brut ascunde mișcările: clienți noi, expansiune, contracție și churn. Un business cu 50.000 USD MRR nou și 30.000 USD MRR pierdut nu crește cu 50.000, ci cu 20.000.

Churn măsoară cât pierzi. Benchmark-urile B2B SaaS pe 2025–2026 (din rapoarte ca Optifai și ChartMogul) pun churn-ul lunar la 3–5% pentru SMB, 1,5–3% pentru mid-market și 1–2% pentru enterprise, cu cei mai buni sub 1%. Detaliu care schimbă strategia: circa 70% din churn se întâmplă în primele 90 de zile — adică onboarding-ul, nu produsul matur, e adesea problema.

LTV (valoarea pe viață a unui client) se calculează corect ca (venit mediu per client × marja brută) ÷ churn lunar — nu pe venit brut, care umflă cifra cu 20–30%. LTV:CAC compară valoarea cu costul de achiziție; pragul minim sănătos e 3:1, iar mediana B2B SaaS privat e în jur de 3,6:1, potrivit datelor Benchmarkit și Optifai. CAC payback (în câte luni îți recuperezi costul de achiziție) s-a înrăutățit — mediana e acum spre 15–20 de luni, față de 12–14 istoric.

NRR (net revenue retention) arată dacă baza existentă crește singură; mediana e în jur de 82%, iar peste 100% e teritoriu de top-quartile. Și marja brută — sănătos 70–85% — îți spune cât poți reinvesti fără capital extern. Pus cap la cap în Rule of 40 (creștere % + marjă de profit % ≥ 40), doar 11–30% dintre companii îl ating.

Nu trebuie să le optimizezi pe toate deodată. Repară-le în lanț: churn → LTV → CAC → NRR. Un singur procent de churn redus de la 5% la 3% aproape dublează LTV-ul.

De la fundamente la build

Straturile, modelele de tenancy, alegerea de billing și metricile sunt deciziile pe care le iei înainte să scrii prima linie de cod de produs. Restul fundamentelor le desfacem pe rând — de exemplu cum alegi concret arhitectura multi-tenant pentru un SaaS și cât costă, de fapt, un build. Vezi și celelalte articole din clusterul de fundamente SaaS.

Un SaaS modern rar trăiește singur. Funcțiile inteligente vin din integrări AI și sisteme RAG; joburile de fundal (dunning, sincronizări, rapoarte nocturne) sunt teren pentru agenți autonomi; datele externe care alimentează produsul vin prin pipeline-uri de web scraping; iar partea de admin și operare internă se suprapune des cu dashboards și tooling intern de tip ERP.

Întrebări frecvente

Ce înseamnă, pe scurt, multi-tenant?

Un singur cod și o singură infrastructură servesc mai mulți clienți (tenanți), cu datele fiecăruia izolate logic sau fizic. E modelul care face ca al 1.000-lea client să coste o fracțiune din primul.

Stripe sau Paddle pentru un SaaS din România?

Depinde de unde vinzi. Dacă ai clienți în zeci de țări și nu vrei să gestionezi TVA-ul peste tot, un Merchant of Record ca Paddle simplifică enorm, la o taxă mai mare. Dacă vinzi mai concentrat și ai resurse de finanțe, un procesator ca Stripe îți dă control și cost de bază mai mic. Mulți pornesc cu MoR și migrează la procesator la scară.

Pot începe cu schemă comună și să trec la bază-per-tenant mai târziu?

Tehnic da, dar e scump: rearhitecturarea după sute de clienți poate dura 6–12 luni. Recomandarea uzuală e să pornești în pool cu RLS și să oferi izolare dedicată ca upgrade pentru clienții enterprise, păstrând o cale clară de migrare.

Ce metrică urmăresc prima dată?

Churn-ul, fiindcă alimentează tot restul (LTV, NRR, Rule of 40). Și fiindcă majoritatea churn-ului apare în primele 90 de zile, prima pârghie e onboarding-ul, nu o funcție nouă.

Cât durează să construiești partea de billing?

Cu un procesator ca Stripe, un sistem complet de abonamente (checkout, webhooks, portal client, dunning) ia tipic 2–4 săptămâni de dezvoltare; cu un MoR, integrarea de bază poate fi gata în câteva zile, fiindcă plata, taxele și UI-ul de checkout vin la pachet.

Construiești un SaaS și vrei fundamentele puse corect de la prima decizie de arhitectură? Explorează serviciul de dezvoltare SaaS și pornește de la stratul care îți blochează acum produsul.