Cum lansezi un MVP în 6 săptămâni

Șase săptămâni sunt suficiente pentru a lansa un produs digital funcțional — dacă știi exact ce construiești și ce lași pe mai târziu. Am trecut prin acest proces de mai multe ori și am identificat un ritm care funcționează: câte o săptămână dedicată fiecărei faze, fără paralelism forțat și fără perfecționism prematur.

Notă: acest articol e despre execuție. Dacă ești încă în faza de decizie asupra ce să includă MVP-ul, citește mai întâi acest ghid.

Săptămâna 1 — Claritate totală înainte de orice cod

Prima săptămână nu se scrie nicio linie de cod. Se definește produsul.

• Lista de funcționalități împărțită în două coloane: „trebuie la lansare" și „poate veni după". Orice funcționalitate din a doua coloană nu există pentru următoarele 6 săptămâni.
• Fluxurile principale descrise ca user stories simple: „Ca utilizator, vreau să mă pot înregistra cu email și să văd o listă de produse disponibile."
• Decizii tehnice de bază: platformă (web, mobile, ambele), stack (Flutter, Next.js etc.), hosting, bază de date. Luate o dată, nu renegociate.

Livrable: un document de 1-2 pagini cu scope-ul clar și o listă scurtă de întrebări fără răspuns (care vor fi validate cu utilizatori reali după lansare).

Săptămâna 2 — Design și arhitectură

Wireframe-uri pentru fiecare ecran principal — nu trebuie să fie perfecte vizual, trebuie să răspundă la întrebarea „ce vede utilizatorul și ce poate face?". Dacă ai deja un brand sau un designer, acum e momentul să obții fișierele Figma.

Simultan, pe parte tehnică: structura bazei de date, endpoint-urile API principale, arhitectura de autentificare. Deciziile luate acum influențează viteza din săptămânile 3-5 — merită 2-3 ore de gândit bine înainte de a tasta prima linie.

Livrable: wireframe-uri validate cu 2-3 utilizatori potențiali (da, chiar acum, nu după lansare) și schema bazei de date aprobată.

Săptămânile 3-4 — Dezvoltare core

Aici se scrie cel mai mult cod. Focusul e exclusiv pe fluxurile critice identificate în săptămâna 1 — autentificare, funcționalitatea principală, integrarea de plăți dacă există.

Câteva reguli pe care le aplic în această fază:

• Nu optimizezi prematur. Dacă ceva funcționează și nu va deveni bottleneck la primii 100 de utilizatori, merge așa.
• Nu adaugi funcționalități noi. Orice idee bună apărută în această perioadă intră pe o listă separată pentru v2 — nu în sprint-ul curent.
• Deploy zilnic pe un mediu de staging accesibil clientului. Surprizele de la final de proiect dispar când feedback-ul vine continuu.

Livrable la finalul săptămânii 4: o versiune funcțională a tuturor fluxurilor principale, pe staging, gata de testat.

Săptămâna 5 — Polish și testare

Această săptămână nu adaugă funcționalități noi. Se rafinează ce există: mesaje de eroare clare, stări de loading, edge cases evidente (ce se întâmplă dacă lista e goală? dacă plata eșuează?).

Testare manuală completă pe dispozitive reale — nu doar în simulator. Dacă e o aplicație mobilă, testez pe cel puțin un iPhone mai vechi și un Android din gama medie. Performanța pe dispozitive premium e înșelătoare.

Dacă ai buget, 2-3 utilizatori reali care testează aplicația în această săptămână valorează mai mult decât orice tool automat de QA.

Săptămâna 6 — Lansare și primele 48 de ore

Lansarea nu e un eveniment, e un proces. Câteva lucruri de bifat înainte de a face link-ul public:

• Analytics de bază instalat (GA4 sau Mixpanel) — nu poți îmbunătăți ce nu măsori
• Monitorizare erori (Sentry sau similar) — vrei să afli tu primul când ceva nu merge
• Backup automat al bazei de date
• Domeniu propriu și SSL
• Email de confirmare pentru acțiunile importante

În primele 48 de ore după lansare, stai aproape. Primele erori reale apar când utilizatori reali fac lucruri pe care nu le-ai anticipat. Răspunde rapid — impresia din prima zi contează disproporționat de mult pentru retenție.

Ce sabotează cel mai des acest plan

• Scope creep: „Hai că mai adăugăm și X, nu durează mult." Durează întotdeauna mai mult decât pare și fiecare adăugare împinge lansarea.
• Perfecționismul UI: pixel perfect de la prima versiune nu e un obiectiv valid pentru un MVP. Utilizatorii iartă un design imperfect dacă produsul rezolvă o problemă reală.
• Decizii tehnice reluate: schimbarea stack-ului sau a arhitecturii după săptămâna 2 resetează practic tot progresul.
• Feedback prea târziu: dacă utilizatorii văd produsul prima oară la lansare, e prea târziu să mai schimbi ceva fundamental.

Concluzie

6 săptămâni sunt un cadru realist pentru un MVP cu 2-4 fluxuri principale, nu pentru un produs complet. Scopul nu e să lansezi ceva perfect — e să lansezi ceva real, din care înveți ce să construiești în continuare.

Dacă vrei să aplicăm acest plan pentru proiectul tău concret, scrie-mi — putem ieși din prima discuție cu un plan adaptat exact la ce construiești tu.