Viteza contează cel mai mult când cauți product-market fit, așa că arhitectura de la început ar trebui să fie simplă, ușor de înțeles și ieftin de schimbat. Capcana e că MVP-ul care validează piața nu ajunge să fie rescris — ajunge să fie extins, sub presiune, de o echipă tot mai mare. Deciziile pe care le-ai luat ca să te miști repede devin constrângerile cu care rămâi. Ideea nu e să complici arhitectura prea devreme; e să iei decizii care sunt ieftine acum și rămân ieftine și mai târziu.
Optimizează pentru schimbare, nu pentru scalare
Aproape niciodată nu știi dinainte ce parte a produsului va avea nevoie să scaleze, așa că nu investi din start în scalare de care s-ar putea să nu ai nevoie vreodată. Investește, în schimb, în capacitatea de a schimba lucrurile ușor: limite clare între module, o schemă pe care o poți migra și disciplina de a ține logica de business în afara framework-ului. Un cod ușor de schimbat poate fi scalat atunci când nevoia chiar apare; unul „scalabil” prea devreme e de cele mai multe ori doar greu de modificat.
Deciziile scumpe de inversat
- Modelul tău de date — migrările devin tot mai grele cu fiecare rând și fiecare integrare.
- Autentificarea și tenancy-ul — adăugarea ulterioară a multi-tenancy-ului sau a autentificării corecte este dureroasă.
- Contractele API publice — odată ce clienții depind de ele, nu le mai poți schimba după bunul plac.
- Unde păstrezi starea aplicației (state) — dacă o muți mai târziu, atingi tot ce o citește.
Restul păstrează-l simplu și ușor de înlocuit
Pentru tot ce nu e scump de schimbat, alege tehnologii consacrate și bine cunoscute și ține-le în spatele unor limite curate, ca să le poți înlocui. Arta unui MVP care devine fundație stă în a ști exact scurta listă de decizii care merită luate cum trebuie de la început — și în a investi cu bună știință mai puțin în tot restul, până când produsul îți arată unde să pui banii.
Construită astfel, prima ta versiune nu e datorie tehnică. E cel mai mic lucru care poate crește.