Cum aș construi un MVP - și cum aș alege de fapt stiva

Dacă m-ai cere mâine să construiesc un MVP, nu aș deschide o comparație a 40 de cadre. Nu aș desena o hartă cu microservicii. Nu aș „preveni în viitor” un produs care nu a întâlnit niciodată un utilizator plătitor. Aș scrie o propoziție: pentru cine este, ce meserie face și ce vom măsura în patru săptămâni. Stiva vine după acea propoziție - nu înainte.

Majoritatea MVP-urilor eșuate nu sunt prea mici. Sunt false-mare: o „platformă” pe jumătate construită cu auth, tablouri de bord, notificări și trei medii - și încă nimeni nu finalizează singura lucrare care ar dovedi ideea. Tehnologia este de obicei alibi. Acest articol este modul în care aș expedia de fapt.

1. Ce este un MVP - și ce refuz să-l numesc

MVP nu este „versiunea 1 cu mai puține ecrane”. Este cel mai ieftin experiment care poate ucide sau întări cea mai riscantă presupunere. Dacă presupunerea este „oamenii vor plăti pentru a rezerva acest serviciu online”, MVP-ul este un flux de rezervare plus o plată plus o persoană la celălalt capăt - nu un CRM, nu un program de loialitate, nu o aplicație nativă.

• Viabil înseamnă că un utilizator real poate termina o lucrare reală. Un prototip Figma pe care se poate face clic este cercetare, nu un MVP.
• Minimum înseamnă că tot ceea ce nu servește acel loc de muncă este un bilet ulterior - chiar dacă pare „ușor de adăugat”.
• Produsul înseamnă că îl puteți repeta săptămâna viitoare fără eroism. Un formular Google plus o foaie de calcul poate fi un MVP. O rescrie a arhitecturii Netflix nu poate.

2. Cinci întrebări înainte ca orice depozit să existe

Argumentele stivelor sunt ieftine. Întrebările despre produse fără răspuns sunt scumpe. Nu aleg Postgres versus Mongo până nu pot răspunde la acestea cu voce tare - cu fondatorul, nu cu o postare pe blog.

• Cine sunt primii zece utilizatori, numiți dacă este posibil - nu „toată lumea cu un telefon”.
• Care este singurul loc de muncă pentru care angajează produsul luna aceasta? Unul. Nu o platformă.
• De unde vin banii sau semnalul - taxa card, contract semnat, slot rezervat, lead calificat?
• Ce constrângere este reală: patru săptămâni, un dezvoltator, un domeniu reglementat, un CRM existent, un Telegram audiență?
• Ce ne-ar face să ne oprim? Dacă nu putem numi un criteriu de ucidere, ne construim un hobby, nu un experiment.

3. Cinci filtre pe care le folosesc pentru a alege tehnologia

Nu aleg instrumente pentru că sunt în tendințe. Le aleg pentru că supraviețuiesc contactului cu un dezvoltator solo, un buget mic și primul utilizator furios. Fiecare tehnologie trebuie să treacă aceste filtre.

• Este timpul pentru primul utilizator real. Dacă stiva se adaugă cu o săptămână înainte ca cineva să poată face clic, este stiva greșită pentru un MVP. Uneltele plictisitoare pe care le expediez deja în producție depășesc una la modă pe care l-aș învăța în termen.
• Operabilitate pentru o singură persoană. Ar trebui să fiu capabil să implementez, să citesc jurnalele, să restabiliz o copie de rezervă și să rotesc o cheie fără o echipă de platformă. Kubernetes nu reușește acest test pentru aproape fiecare produs timpuriu.
• Închiriabil și înlocuibil. TypeScript, Postgres și React nu sunt interesante. Sunt limbile pe care le vorbesc deja alți oameni buni. Un MVP pe care numai eu îl pot extinde este un ostatic, nu un atu.
• Gravitatea datelor. Pune sursa adevărului într-o bază de date reală cu migrări din prima zi dacă produsul are utilizatori și bani. Foile de calcul sunt bune pentru experimentul de lângă produs - nu în interiorul casetei.
• Trapa de evacuare. Voi folosi o autentificare gestionată, un Postgres găzduit, un furnizor de plăți. Nu voi semna un blocaj de cinci ani care face exportul dureros. Furnizorul este bine. Capcana nu este.

4. Stiva web implicită cu care aș începe în 2026

Pentru un B2B tipic sau MVP de servicii - rezervare, captare de clienți potențiali, un mic portal pentru clienți, un calculator care se transformă într-o ofertă - aș începe aici. Nu pentru că ar fi la modă. Pentru că îl pot expedia, îl pot SEO și încă pot să angajez pe altcineva în șase luni.

• Next.js + TypeScript + Tailwind: o aplicație pentru pagini de marketing (SEO, randare pe server) și interfața de utilizare a produsului. Mai puține repoziții, o singură implementare, tipuri partajate. App Router este în regulă dacă echipa îl știe deja; Nu voi rescrie o aplicație Pages funcțională „pentru puritate”.
• Postgres (adesea prin Supabase, Neon sau un mic VPS): date relaționale, tranzacții și SQL pe care le pot inspecta la ora 2 a.m. Mă îndrept către un depozit de documente numai atunci când forma este într-adevăr în formă de document - nu pentru că „NoSQL este mai rapid”.
• Auth: un furnizor gestionat (Clerk, Auth.js + un IdP cunoscut sau Supabase Auth), cu excepția cazului în care produsul este autentificarea. Derularea sesiunilor personalizate în săptămâna întâi este modul în care scurgeți jetoane și blocați caracteristica reală.
• Plăți: Stripe (sau echivalentul local pe care primii utilizatori îl folosesc efectiv). Niciun motor de facturare de casă. Facturile pot aștepta; o taxă de lucru nu poate.
• Găzduire: Vercel pentru aplicația Next.js dacă traficul este în formă de web și echipa dorește previzualizări; a Hetzner/VPS + Docker Compune dacă avem nevoie de un lucrător de lungă durată, cost previzibil sau rezidență de date. Am scris despre acest compromis separat - regula MVP este: un mediu pe care îl înțelegeți, backup-uri pe noapte, HTTPS și un domeniu.
• E-mail și fișiere: Retrimiteți sau un API tranzacțional similar; Stocare compatibilă cu S3. Nu „vom construi un modul de atașamente”.

5. Când arunc implicit

O valoare implicită este un pariu de pornire, nu o religie. Îl schimb când constrângerea este produsul.

• Publicul trăiește deja în Telegram: un bot sau Mini App poate fi întregul MVP. Un site web pe care nu îl vor deschide nu este „mai profesionist”. Este o a doua cameră goală.
• Lucrarea este pe teren cu semnal prost: consider o cale local-prim sau PWA, nu o rescriere nativă în prima săptămână. Nativ este o decizie de distribuire, nu o insignă.
• Nucleul este limbajul (suport, citare, extrage document): adaug un LLM API în spatele unei scheme stricte și a unui pas de revizuire umană. Nu împachetez un widget de chat și îl numesc produs.
• Fondatorul este operatorul, iar conținutul este produsul: un site rapid plus un CMS pe care îl vor folosi efectiv pot depăși un administrator personalizat. WordPress este încă permis dacă jobul este publicat, nu o aplicație.
• Piață cu două fețe: încă expediez prima o parte. Oferta sau cererea - oricare dintre acestea este mai greu de obținut. O „platformă” cu locuri goale pe ambele părți este o pagină de destinație cu mese suplimentare.

6. Ce refuz să adaug înaintea primilor utilizatori

Cel mai rapid mod de a rata experimentul este de a construi compania în jurul experimentului. Aceasta este lista pe care o păstrez lângă restanța.

• Microservicii, o magistrală de mesaje și Kubernetes. Un proces, o bază de date, o implementare. Împărțiți atunci când apare un adevărat blocaj sau o graniță reală a echipei - nu atunci când o diagramă pare superioară.
• Un sistem de design cu 80 de jetoane și fără ecrane. Trimiteți cele trei ecrane care colectează bani. Extrageți componente când doare al treilea copy-paste.
• Roluri, permisiuni, jurnalele de audit și SSO - cu excepția cazului în care un cumpărător B2B plătitor a blocat tranzacția pentru ele. Atunci ei sunt MVP, nu o căutare secundară.
• O a doua aplicație mobilă. Web responsive sau o mini-aplicație acoperă primele sute de utilizatori din majoritatea companiilor de servicii pe care le văd.
• Acoperire perfectă de testare a codului de lipici. Vreau teste pentru bani, autentificare și munca de bază. Nu vreau o săptămână de batjocuri pentru un formular de aterizare.

7. Cum ar arăta de fapt primele patru săptămâni

Tratez calendarul ca pe o decizie de produs. Dacă nu putem descrie săptămâni, nu avem un plan - avem o dorință.

• Săptămâna 0 (două zile, nu două săptămâni): scrieți o pagină. Utilizator, job, criteriu ucidere, non-goaluri. Schițați cele trei ecrane. Acceptați ce înseamnă „terminat”: un străin poate finaliza lucrarea fără un apel Zoom de la noi.
• Săptămâna 1: felie verticală. Domeniu, implementare, bază de date, aspect gol, o cale fericită în producție (chiar dacă este urâtă). Dacă nu ne putem desfășura în ziua a treia, stiva stă deja.
• Săptămâna 2: jobul. Rezervare, cotare, încărcare, plată - orice am numit în săptămâna 0. Operațiunile manuale din spatele interfeței de utilizare sunt permise: un ping Telegram către proprietar este o caracteristică dacă închide bucla.
• Săptămâna 3: marginile urâte. Stări goale, erori, mobil, e-mailuri, analize de bază (unde au căzut). Nu un depozit de date. O pâlnie pe care o poți citi.
• Săptămâna 4: pune-l în fața celor zece persoane numite. Ceas. Nu adăugați o funcție în timpul apelurilor. Scrieți ce au făcut în loc de ceea ce au spus că vor.

8. După lansare: păstrați, extrageți sau rescrieți

Un MVP bun are voie să fie ușor jenant. Nu este permis să fie o capcană. Stiva de mai sus este plictisitoare intenționat: poți crește în ea. Rareori trebuie să crești din ea în primul an.

• Păstrați: limba, baza de date, numele de domenii în cod. Acestea sunt ieftine de trăit și scumpe de aruncat.
• Extras: un muncitor, un al doilea serviciu, o coadă reală - când un loc de muncă este lent, periculos sau este deținut de o altă echipă. Nu înainte.
• Rescrie doar partea care a învățat lecția greșită. Dacă finalizarea este greșită, rescrieți finalizarea. Dacă întreaga aplicație este un labirint codificat în vibrații, aceasta este mai întâi o problemă cu oamenii: cineva trebuie să poată explica asta la 2 a.m.

Concluzie: alegeți stiva care supraviețuiește primului nr

Aș construi un MVP într-un mod lipsit de farmec: un loc de muncă, o bază de date, o implementare, instrumente pe care le pot opera singur și o dată la care decidem să continuăm sau să ne oprim. „Cea mai bună” tehnologie este cea care nu ne distrage atenția de la acea decizie. Next.js, TypeScript, Postgres, o autentificare gestionată și un furnizor de plăți nu sunt o personalitate. Sunt o modalitate de a petrece săptămânile rare pe produs și nu pe platformă.

Dacă aveți o idee, un termen limită și o teamă de a alege stiva „greșită” - scrieți prin secțiunea de contacte. Putem stabili un singur loc de muncă, denumim non-obiectivele și livrăm o felie pe care o puteți pune în fața unor oameni reali fără a construi mai întâi o platformă falsă.