Metoda Basetool 6 Săptămâni pentru MVP
Metodologia noastră pentru livrarea unui MVP gata de producție în șase săptămâni. Scop fix, preț fix, trei faze. Exact cum lucrăm.
Cuprins
Când fondatorii întreabă cât durează să construiești un MVP, răspunsul sincer este: depinde de câtă disciplină exercită toată lumea. Am integrat disciplina în structura însăși.
Metoda Basetool 6 Săptămâni pentru MVP este metodologia noastră fixă pentru livrarea unui MVP gata de producție. Nu este un interval sau o estimare. Este containerul. Dacă o funcționalitate nu încape în șase săptămâni, nu intră în acest angajament. Această constrângere nu este o limitare; este produsul.
Procesul nostru pe pagina principală. Iată cum arată în detaliu.
Faza 1: Descoperire și Spec (Săptămânile 1-2)
Primele două săptămâni nu sunt despre scrierea de cod. Sunt despre eliminarea ambiguității înainte ca o singură linie să fie scrisă.
Ce se întâmplă:
- Rulăm un apel structurat de kick-off (de obicei două până la trei ore) pentru a cartografia parcursul de bază al utilizatorului. Un tip de utilizator, un flux, o ipoteză pe care o testăm.
- Producem un spec funcțional: povești de utilizator scrise, wireframe-uri adnotate pentru fiecare ecran și un draft al modelului de date. Nimic nu este lăsat la interpretare.
- Luăm toate deciziile care nu pot fi schimbate ieftin în mijlocul construcției: structura bazei de date, abordarea de autentificare, integrările terților, mediul de hosting.
- Identificăm explicit limita de scop, adică scriem ce NU este în această construcție, astfel încât să nu existe ambiguitate ulterior.
Cine deține ce:
- Tu (fondatorul) deții deciziile de produs: care este fluxul de bază, cine este utilizatorul, cum arată succesul.
- Noi deținem deciziile tehnice: stack, arhitectură, abordarea de deployment.
- Deținem împreună spec-ul: fiecare element este revizuit și aprobat înainte ca Faza 2 să înceapă.
Ce decizii se iau aici:
Cea mai importantă decizie în Faza 1 este linia de scop. O trasăm împreună, și odată trasată, rămâne. Aici se rezolvă MVP-urile supra-scopate, nu prin negociere, ci prin parcurgerea spec-ului și recunoașterea care funcționalități testează ipoteza și care o decorează.
Faza 2: Construcție (Săptămânile 3-5)
Trei săptămâni de dezvoltare concentrată. Spec-ul este sursa de adevăr. Nicio funcționalitate nouă nu intră în construcție în această fază.
Ce se întâmplă:
- Săptămâna 3: Infrastructură de bază. Autentificare, baze de date, schelet de API, pipeline de deployment către un mediu de staging. La sfârșitul Săptămânii 3, URL-ul de staging este live și scheletul produsului poate fi navigat.
- Săptămâna 4: Funcționalități de bază. Parcursul principal al utilizatorului este implementat de la capăt la capăt. Aceasta este etapa în care produsul începe să semene cu ceea ce trebuie să fie.
- Săptămâna 5: Fluxuri secundare și polish. Gestionarea erorilor, cazuri-limită, stări goale, stări de încărcare, layout responsiv. Produsul devine suficient de fiabil pentru a fi arătat utilizatorilor reali.
Ce vezi:
Distribuim URL-ul de staging la sfârșitul Săptămânii 3 și oferim actualizări async săptămânale. Nu ești așteptat să revizuiești fiecare commit, dar ești așteptat să semnalezi orice neînțelegeri ale spec-ului înainte ca Săptămâna 5 să se încheie. Săptămâna 5 este ultimul punct în care o corecție de curs poate avea loc fără a afecta data de lansare.
Disciplina:
Faza 2 are o singură regulă: scopul este înghețat. Dacă identifici o funcționalitate care ar trebui inclusă, o adăugăm pe un backlog post-lansare. Nu ajustăm scopul în mijlocul construcției. Aceasta nu este rigiditate. Este ceea ce face posibilă o lansare în șase săptămâni. Adăugirile de scop în mijlocul construcției nu adaugă timp liniar; îl adaugă exponențial, pentru că creează muncă de integrare, re-testare și suprasarcină cognitivă care se compun.
Faza 3: QA, Polish și Lansare (Săptămâna 6)
Săptămâna finală este structurată în jurul unei singure întrebări: este acest produs gata să fie pus în fața utilizatorilor reali?
Ce se întâmplă:
- Testare cross-browser și cross-device. Verificăm produsul pe mediile pe care utilizatorii tăi le vor folosi efectiv.
- Revizuire a cazurilor-limită: ce se întâmplă când un utilizator face ceva neașteptat? Stări de baze de date goale, plăți eșuate, linkuri de email defecte. Toate acestea sunt exercitate.
- Linie de bază pentru performanță: verificăm că produsul se încarcă suficient de rapid pentru a nu crea fricțiune la prima utilizare.
- Promovare de la staging la producție: mediul este mutat de la staging la producție, cu domeniu real, credențiale reale și o listă de verificare pre-lansare completată.
- Documentație de predare: producem o scurtă documentație tehnică de predare acoperind deciziile de arhitectură, cum să se implementeze actualizări și unde sunt credențialele.
Lansarea:
Definim „lansarea" ca: utilizatorii reali pot să se înregistreze, să folosească produsul și să întâlnească o experiență funcțională. Nu perfecțiune. Funcțional. Distincția contează. Un produs perfect care se lansează în patru luni te-a costat patru luni de învățare. Un produs funcțional care se lansează în șase săptămâni înseamnă șase săptămâni de semnal real.
De ce șase săptămâni
Șase săptămâni nu este un număr rotund ales arbitrar. Este intervalul pe care l-am găsit că menține o echipă de doi-trei ingineri într-un sprint concentrat înainte ca suprasarcina cognitivă a schimbării de context să devină o frână pentru calitate.
Este și intervalul care forțează o conversație despre scop înainte de construcție. Limita de șase săptămâni face disciplina de scop inevitabilă: dacă vrei să lansezi în șase săptămâni, trebuie să alegi ce construiești. Această alegere este în sine valoroasă.
Dincolo de șase săptămâni, scopul tinde să se extindă. Dincolo de zece săptămâni, lucrul construit începe să arate diferit față de cel proiectat la început, pentru că lumea se schimbă și produsul se schimbă odată cu ea, și atunci nu mai testezi o ipoteză, ci construiești un produs pe care speri că piața îl vrea în continuare.
Ce NU este inclus
Pentru a fi direcți despre limitele de scop:
- Nu este inclus: aplicații mobile native. Doar web, responsiv.
- Nu este inclus: un API public sau integrări cu parteneri. Post-lansare.
- Nu este inclus: panouri de administrare dincolo de instrumente operaționale de bază. Ești propriul tău administrator.
- Nu este inclus: tablouri de bord analitice complexe. O integrare standard de analiză este inclusă; raportarea personalizată nu este.
- Nu este inclus: suport multilingv. O singură localizare.
- Nu este inclus: design personalizat de șabloane email. Emailul tranzacțional funcțional este inclus; campaniile HTML de email de brand nu sunt.
Acestea nu sunt gânduri de ultimă oră. Sunt intenționate. Tot ce este pe această listă poate fi construit în faza de după ce ai validat că produsul de bază funcționează.
Întrebarea prețului fix
Metoda Basetool 6 Săptămâni pentru MVP operează pe scop fix și o structură de angajament fixă. Buget previzibil, fără derivă de scop.
Aceasta necesită ca scopul să fie cu adevărat fix. Scopul variabil cu un preț fix nu este un model de prețuri. Este un conflict care așteaptă să se întâmple. Când ne înțelegem asupra scopului în Faza 1 și ambele părți îl aprobă, prețul este fix pentru că munca este fixă. Dacă scopul se schimbă după Faza 1, discutăm impactul înainte de a continua.
Cum începem
Dacă ai o idee și vrei să înțelegi dacă se potrivește modelului de șase săptămâni, Estimatorul de MVP este locul de pornire. Parcurge deciziile de scop și scoate la iveală compromisurile înainte să avem o conversație.
Dacă ești deja clar asupra a ceea ce vrei să construiești, contactează-ne direct. Faza de Descoperire începe cu un apel, iar apelul este începutul spec-ului.
Această metodologie reflectă cum lucrăm la Basetool Labs în 2026. Evoluează pe măsură ce învățăm.