Merită să construiesc aplicația asta? 5 întrebări înainte de prima linie de cod

Ai o idee de aplicație. Poate o porți de luni de zile, poate ți-a venit săptămâna trecută și nu te lasă să dormi. Întrebarea pe care o pui prietenilor, cofondatorului sau primului developer cu care vorbești este aproape mereu aceeași: cât ar costa s-o construim. E întrebarea greșită, sau cel puțin e a doua întrebare. Prima e dacă merită construită deloc.

Construiesc produse de opt ani, dintre care șase pe sisteme AI, și am văzut tiparul de prea multe ori. Cineva investește luni și economii într-o aplicație îngrijită, bine făcută, pe care nu o vrea nimeni. Codul e curat. Problema e că rezolvă o problemă pe care nimeni nu plătește s-o rezolve. Cele cinci întrebări de mai jos sunt filtrul prin care trec eu o idee înainte de prima linie de cod.

1. Există o problemă reală pe care cineva o plătește s-o rezolve?

Aici cad cele mai multe idei, și cad tăcut. Diferența nu e între o problemă reală și una imaginară. Aproape orice idee rezolvă o problemă reală pentru cineva. Diferența e între o problemă pe care oamenii o resimt suficient de tare cât să plătească pentru o soluție și una pe care o recunosc politicos când îi întrebi.

Testul nu e „ți-ar plăcea să existe asta?”. La întrebarea asta toată lumea spune da. Testul e: ce faci acum în locul soluției mele, cât te costă faptul că nu există, și ai plăti cât cer pentru ea? Dacă oamenii deja improvizează cu Excel, plătesc pe cineva manual sau au încercat alte produse și le-au abandonat, ai un semnal. Dacă reacția e „interesant”, nu ai.

Greșeala scumpă nu e să construiești prost. E să construiești bine lucrul de care nu are nimeni nevoie.

2. Cine e, concret, persoana care o are?

„Toată lumea” nu e un client. Cu cât e mai larg publicul pe care îl descrii, cu atât e mai probabil că nu ai vorbit cu suficienți oameni reali. Un produs bun la început rezolvă o problemă acută pentru un grup îngust și clar definit, nu o problemă vagă pentru toți.

Întrebarea concretă: poți numi zece oameni, cu nume și context, care au problema acum? Dacă da, ai pe cine suna înainte să construiești. Dacă nu, primul pas nu e codul, e să-i găsești și să le vorbești. Aplicația ta va trebui oricum vândută cuiva anume. E mai ieftin să afli cine e acel cineva înainte, nu după ce ai cheltuit bugetul de dezvoltare.

3. Care e cea mai simplă variantă care rezolvă problema?

Aproape fiecare fondator confundă produsul pe care și-l imaginează cu produsul de care are nevoie ca să înceapă. MVP-ul (minimum viable product) nu e o versiune mai mică și mai urâtă a viziunii tale. E cel mai mic lucru care îți răspunde la o întrebare: oamenii folosesc asta și ar plăti pentru ea?

Disciplina aici e brutală. Un singur flux. O singură problemă rezolvată cap-coadă. Tot ce ai adăuga „ca să fie complet” e, de fapt, o ipoteză netestată care îți întârzie singura informație care contează. La ai-aflat.ro, asistentul AI pentru legislația din România pe care l-am construit, prima versiune făcea un singur lucru: răspundea la întrebări despre legi. A ajuns la ~15.000 de utilizatori și peste 120.000 de interogări, cu buget de marketing zero, pentru că rezolva clar o problemă, nu pentru că avea multe funcții.

4. Cât costă s-o ții în funcțiune după ce o construiești?

Costul pe care îl vede toată lumea e cel de construcție. Costul care ucide produsele e cel de întreținere. O aplicație nu e o cheltuială unică, e un cost recurent: servere, mentenanță, securitate, actualizări, suport pentru utilizatori, schimbări când se schimbă platformele de care depinzi. TCO (total cost of ownership) e suma reală, iar de obicei o ignorăm complet la decizie.

Întrebarea pe care merită s-o pui înainte de a începe: dacă produsul are succes moderat, dar nu suficient cât să se susțină singur, cât te costă lunar să-l ții viu, și cât timp poți susține asta din alte surse? Multe produse nu mor pentru că au eșuat. Mor pentru că au reușit puțin, iar costul de a le ține în funcțiune a depășit ce era fondatorul dispus să plătească pe termen lung.

5. Ce nu știi încă, tehnic, despre ce vrei să construiești?

Nu trebuie să fii inginer ca să iei decizia. Trebuie să-ți cunoști zonele de necunoscut. Fiecare idee are una sau două ipoteze tehnice de care depinde totul: integrarea aceea funcționează cum crezi? Modelul AI poate face într-adevăr ce presupui? Datele de care ai nevoie sunt disponibile și legale de folosit? Volumul pe care îl visezi e fezabil pe bugetul pe care îl ai?

Aceste necunoscute sunt cele mai ieftin de testat la început și cele mai scumpe de descoperit la final. O conversație cu cineva care a construit ceva similar, sau un mic prototip pe partea riscantă, costă zile. Aceeași descoperire făcută după șase luni de dezvoltare costă tot proiectul. Dacă alegerea tehnologiei te blochează aici, am scris separat despre cum aleg tehnologia potrivită fără să fiu inginer.

Construiesc, folosesc no-code sau cumpăr ceva gata făcut?

Presupunând că ai trecut de primele patru întrebări, mai e o decizie pe care prea mulți o sar: nu trebuie neapărat să construiești de la zero. Adesea cea mai bună mișcare e să nu construiești deloc la început.

Logica e simplă. Dacă o soluție existentă rezolvă deja problema, cumperi și economisești luni. Dacă problema e standard dar nu găsești potrivirea exactă, no-code te duce la validare repede și ieftin. Construiești de la zero doar când miezul a ceea ce faci e diferit de tot ce există și acolo e avantajul tău. Înainte de a alege agenția care să construiască, merită să fii sigur că vrei sfat sau execuție, diferența dintre un Tech Coach și o agenție e exact cea care îți spune dacă ești deja în etapa de construit.

Cadrul de decizie: ce faci cu cele cinci răspunsuri

Pune cele cinci întrebări pe rând și fii onest. Nu cauți cinci „da”, cauți unde e veriga slabă.

• Dacă pici la problema (nimeni nu plătește), te oprești și revalidezi. Nu e o problemă de cod.
• Dacă pici la clientul (nu poți numi zece oameni), primul pas sunt zece conversații, nu un developer.
• Dacă pici la cea mai simplă variantă (vrei să construiești totul), tai până rămâne un singur flux.
• Dacă pici la costul de întreținere (nu te poți susține dacă merge moderat), regândești modelul înainte, nu după.
• Dacă pici la necunoscutele tehnice (nu știi dacă partea grea e fezabilă), testezi acea ipoteză înainte de orice altceva.

Răspunsul onest, după cele cinci întrebări, e foarte des „încă nu, nu așa”. Asta nu e un eșec. E exact momentul în care economisești cele șase luni și banii pe care i-ai fi cheltuit construind versiunea greșită. Un „încă nu” clar valorează mai mult decât un „da” încețoșat.

Eu fac exact acest exercițiu cu fondatori în fiecare săptămână. Nu îți scriu codul și nu îți iau decizia. Te ajut să treci ideea prin filtrul ăsta cu cineva care a construit produse la mize reale și să vezi singur unde stă. Cine e cel care îți pune întrebările contează, restul poveștii e pe vladtudor.com.