Cum construiești un SaaS MVP: de la idee la primul client

Ai decis deja cum arată arhitectura. Știi ce model de multi-tenancy folosești, cum izolezi datele între clienți, ce conține schema. Urmează partea în care majoritatea proiectelor se împotmolesc: cum construiești efectiv un SaaS MVP, de la primul commit la primul client care plătește.

Și aici apare confuzia. Build-ul nu e, în esență, o problemă de cod. E o secvență de decizii de scope. Ce intră în prima versiune, ce amâni intenționat, unde tragi linia și spui „atât, livrez". Un founder care scrie cod impecabil, dar nu taie scope-ul, livrează în opt luni. Unul care taie agresiv și acceptă imperfecțiunea livrează în trei.

Ghidul ăsta tratează fiecare etapă a build-ului ca pe un trade-off, nu ca pe un tutorial de programare. Cum tai scope-ul, ce stack alegi pragmatic în 2026, ce piese rămân non-negociabile chiar și în v1 și cum arată secvența reală de la schelet la primul abonament.

Build-ul e o secvență de decizii, nu de cod

Un MVP nu e produsul tău final în miniatură. E cel mai mic lucru pe care un client real ar plăti ca să-l folosească. Diferența e enormă și se vede direct în timeline.

Întrebarea care taie scope-ul cel mai rapid e brutal de simplă: ai putea vinde produsul primilor 10 clienți fără funcția asta? Dacă răspunsul e da, nu intră în MVP. Punct. Nu „o adaug repede", nu „e doar o zi de muncă". Fiecare „doar o zi" se adună într-o lună de slip.

Dacă încă te întrebi ce înseamnă exact un produs SaaS și prin ce diferă de un software clasic vândut o dată, pornește de la ce este un SaaS și cum funcționează modelul. Aici presupunem că ai trecut deja de pasul ăla.

Taie scope-ul: ce intră în v1, ce amâni

Există un exercițiu cunoscut sub numele de „80% Cut". Listezi toate funcțiile la care te-ai gândit, tai la setul minim care livrează promisiunea de bază unei singure persona, apoi mai tai 20%. Majoritatea listelor ambițioase nu supraviețuiesc exercițiului — exact ăsta e scopul.

Concret, pentru un SaaS B2B nou: Intră în v1: o singură funcție centrală care livrează valoarea reală; un singur tip de utilizator; auth; izolare per tenant; un flux funcțional prin care clientul plătește; un dashboard minim prin care vede ce a făcut.

Amâni intenționat: onboarding automat complex (la 10 clienți, un apel cu tine e un onboarding mai bun decât orice secvență automată); roluri și permisiuni fine; integrări multiple cu servicii externe; orice funcție care contează la 1.000 de utilizatori când tu ai 10; polish vizual excesiv pe ecrane secundare.

Regula de aur: amâni tot ce nu blochează primul client să plătească. Restul e zgomot care îți mănâncă săptămâni.

Stack-ul pragmatic pentru un SaaS B2B nou

Într-un articol conceptual ai compara opțiuni la nesfârșit. Într-un build real alegi un stack și mergi cu el. Un stack opinionat, ales o dată și nerevizuit, e una dintre condițiile care țin timeline-ul în frâu — potrivit analizelor de MVP din 2026, fiecare alegere „exotică" sau revizuită la mijlocul build-ului adaugă săptămâni.

Iată un stack best-fit pentru un SaaS B2B nou, cu justificarea fiecărui strat.

Framework: Next.js

Potrivit Vercel, Next.js 16 a devenit major-ul stabil în octombrie 2025, cu Turbopack ca bundler default și Node.js 20+ ca minim; la momentul scrierii, linia 16.2.x e cea curentă. Un singur framework îți dă frontend, API routes și server-side rendering. Pentru un SaaS B2B unde contează time-to-market, asta înseamnă o singură bază de cod și un singur deployment, nu trei servicii pe care le ții în sincron.

Baza de date: Postgres

Postgres e alegerea predictibilă: relațional, matur, cu suport bun pentru izolarea per tenant pe care ai decis-o deja în faza de arhitectură multi-tenant. Nu ai nevoie de ceva mai exotic în v1. O bază de date pe care o cunoști bate o bază de date „la modă" pe care o înveți în timp ce livrezi.

Auth: nu reinventa roata

Aici e o capcană tentantă: „scriu eu auth, nu e greu". E o decizie de securitate, nu de confort, iar peisajul s-a schimbat. Lucia, biblioteca minimalistă populară, a fost depreciată în martie 2025 și a devenit resursă educațională, nu o opțiune pentru proiecte noi.

Pentru un build din 2026 rămân trei direcții realiste: Auth.js v5 (fostul NextAuth), solid și cu cel mai larg suport de provideri OAuth; Better Auth, alternativa modernă apărută în 2025, gândită nativ pe TypeScript; sau un serviciu managed precum Clerk, care oferă componente UI gata făcute și un tier gratuit până la 10.000 de utilizatori activi lunar. Open-source îți dă control deplin; managed îți cumpără timp. Pentru un MVP cu deadline, timpul e adesea mai valoros decât controlul.

Billing: aici se complică pentru România

Billing-ul nu e doar „integrează Stripe". E o decizie cu implicații fiscale directe pentru tine, ca firmă din România care vinde global.

Sunt două modele. Cu un payment processor precum Stripe direct plătești în jur de 2.9% + $0.30 per tranzacție, dar rămâi tu responsabil de TVA: Stripe Tax calculează, însă tu depui și remiți declarațiile în fiecare jurisdicție. Cu un merchant of record (MoR) — Paddle, Lemon Squeezy sau noul Stripe Managed Payments — entitatea aceea devine vânzătorul legal și gestionează TVA/GST în locul tău, contra a aproximativ 5% + $0.50 per tranzacție.

Contextul din 2026 contează aici. Stripe a achiziționat Lemon Squeezy în 2024, iar din februarie 2026 a lansat Stripe Managed Payments, propriul produs MoR (aflat în public preview), care aplică statutul de merchant of record la nivel de tranzacție, nu pe tot contul. Paddle rămâne un MoR consacrat care gestionează VAT în peste 200 de țări, deși rata efectivă urcă spre 7% după conversia valutară.

Pentru un founder din România la început, un MoR elimină exact bătaia de cap care te-ar bloca luni întregi: înregistrarea de TVA și depunerile în zeci de jurisdicții. Detaliile de conformitate fiscală locală — TVA și e-Factura pentru un SaaS din România — merită tratate separat, într-un ghid dedicat conformității fiscale.

Piesele non-negociabile chiar și în v1

Poți amâna aproape orice. Câteva lucruri, însă, nu se amână — sunt fundația, nu funcții:

• Auth. Email și parolă plus cel puțin un provider OAuth. Fără identitate nu ai cum să legi date de un client.
• Multi-tenancy. Izolarea datelor între clienți pe care ai decis-o în arhitectură se construiește din prima zi, nu se „adaugă mai târziu". Retrofitarea izolării pe o bază de date care n-a fost gândită pentru ea e una dintre cele mai scumpe rescrieri posibile.
• Billing. Un flux funcțional prin care un client poate plăti. Fără el nu ai un SaaS, ai un demo.
• Un minim de observabilitate. Logging structurat și erori vizibile. Când primul client lovește un bug la 23:00, ai nevoie să vezi ce s-a întâmplat, nu să ghicești.

Dincolo de astea, multe SaaS-uri au nevoie din start de procesări care rulează în fundal — un import de date, un raport generat nocturn, un email programat. Sunt joburi de fundal care rulează fără supraveghere, invizibile pentru utilizator, dar fără ele fluxul principal se blochează. Dacă MVP-ul tău are o funcție AI — căutare semantică sau un asistent peste documentele clientului — tratează stratul de AI și RAG ca pe o piesă separată, cu propriile costuri și riscuri. Iar dacă produsul depinde de date externe, pipeline-ul de extragere și structurare e tot o decizie de build, nu un detaliu de lăsat pe ultima sută de metri.

O notă de scope: dacă ce construiești e de fapt un dashboard intern pentru operațiuni, nu un produs cu abonament vândut în afară, atunci billing-ul iese din ecuație și prioritățile se mută complet. Asigură-te că știi în ce categorie ești înainte să alegi piesele.

Secvența reală de build a unui SaaS MVP: de la schelet la primul plătitor

Ordinea contează enorm. Greșeala clasică e să construiești funcția „cool" prima și să lași auth-ul, deployment-ul și billing-ul la final. Inversează. Pune scheletul live devreme — auth, izolare per tenant, un deployment care merge — apoi construiește valoarea peste un schelet care deja funcționează.

Fiecare fază are un gate — un criteriu clar de „gata" înainte să treci mai departe. Asta previne scenariul în care ești în săptămâna a noua și totul e încă „aproape gata". Validarea și scope-ul vin primele, înainte de orice linie de cod: un spec clar și o listă de clienți reali pe care îi poți suna. Scheletul transformă deciziile de arhitectură în ceva live. Funcția principală e singura piesă de „produs" și primește cel mai mult timp. Billing-ul și hardening-ul închid bucla comercială și operațională. Abia apoi vine primul client real, al cărui feedback decide ce construiești în continuare — nu lista ta de funcții de dinainte.

Cât durează, de fapt, și cu ce echipă

Onestitate brutală pe timeline. Potrivit analizelor de MVP din 2026, un SaaS MVP lean realist e între 9 și 18 săptămâni — adică 3–5 luni dacă ești sincer cu tine. Faza de build propriu-zisă e 6–8 săptămâni doar dacă scope-ul e bine definit și deciziile tehnice luate înainte de prima linie de cod; 10–12 săptămâni e mai frecvent.

Echipa schimbă totul. Timeline-ul de 8 săptămâni presupune o echipă de 3–4 oameni cu workstream-uri paralele — designul merge înaintea engineering-ului, QA-ul nu așteaptă la final. Un dezvoltator solo, care lucrează secvențial, are nevoie de 14–20 de săptămâni pentru exact același scope. Excepția: un senior solo, cu un stack pe care îl știe bine și disciplină agresivă de scope, poate atinge 10–12 săptămâni.

Și nu uita partea de după lansare. Mentenanța consumă, conform benchmark-urilor din industrie, între 15% și 25% din costul inițial, anual. MVP-ul nu e linia de sosire, e linia de start. Despre cât costă efectiv un build de SaaS de la cap la coadă vorbim separat.

Capcanele care transformă 8 săptămâni în 16

Trei tipare se repetă la aproape orice build care derapează: Over-engineering. Construiești pentru 1.000 de utilizatori când ai zero. Abstracțiuni premature, microservicii inutile, infrastructură pe care „o să o folosești cândva". Fiecare alegere non-default adaugă timp pe care nu-l ai.

Build înainte de validare. Cea mai scumpă greșeală dintre toate. Construiești șase săptămâni un produs pe care nimeni nu l-a confirmat că-l vrea. Testul celor 10 clienți există tocmai ca să descoperi problemele de scope acum, când sunt ieftine, nu în săptămâna a șasea, când sunt scumpe.

Feature creep. Adaugi funcții pentru că ești nervos să arăți produsul oamenilor. Asta nu e dezvoltare, e amânare deghizată. Nu ești gata de lansare când mai adaugi „încă o funcție ca să fie sigur". Ești gata când fluxul de bază rezolvă problema suficient cât cineva să scoată cardul.

Întrebări frecvente

Cât durează să construiești un SaaS MVP?

Realist, 9–18 săptămâni pentru un MVP lean, potrivit analizelor de MVP din 2026. Faza de build pură e 6–8 săptămâni cu scope clar și echipă dedicată, dar 10–12 e mai comun. Dacă lucrezi solo, dublează intervalele.

Pot construi singur un MVP, fără echipă?

Da, dar fii onest cu tine: un dezvoltator solo are nevoie de 14–20 de săptămâni pentru un scope pe care o echipă de 3–4 îl livrează în 8. Un senior cu stack familiar și scope tăiat agresiv poate coborî la 10–12 săptămâni.

Ce stack aleg dacă pornesc de la zero în 2026?

Un stack opinionat best-fit: Next.js (linia 16.2.x e stabilă, pe Node.js 20+), Postgres, un strat de auth (Auth.js v5, Better Auth sau Clerk) și un strat de billing. Important nu e care opțiune e „cea mai bună" în absolut, ci să alegi o dată și să nu revizuiești la mijlocul build-ului.

Trebuie să am billing din prima versiune?

Da. Fără un flux prin care un client poate plăti, nu ai un SaaS, ai un demo. Billing-ul e non-negociabil în v1, alături de auth și de multi-tenancy.

Folosesc un merchant of record sau Stripe direct?

Depinde de cine duce povara TVA. Stripe direct e mai ieftin (în jur de 2.9% + $0.30), dar tu depui declarațiile fiscale. Un MoR precum Paddle, Lemon Squeezy sau Stripe Managed Payments costă în jur de 5% + $0.50, dar devine vânzătorul legal și gestionează TVA global. Pentru un founder din România la început, un MoR elimină cea mai mare bătaie de cap administrativă.

Când e gata MVP-ul de lansat?

Când fluxul de bază rezolvă problema suficient cât cineva să plătească — nu când ți se pare „perfect". Dacă mai adaugi funcții din nervozitate, amâni, nu dezvolți.

Pasul următor

Un MVP bun e o serie de decizii de scope disciplinate, nu o demonstrație de cod. Taie agresiv, alege un stack și mergi cu el, păstrează non-negociabilele și livrează până la primul client real. Dacă vrei să vezi cum se leagă build-ul de restul deciziilor de produs, explorează serviciul SaaS complet sau celelalte ghiduri din categoria Build și MVP SaaS.