← Toate articolele

Cât costă o aplicație? De ce e întrebarea greșită

Publicat · de theCoders · 15 min de citit
Cât costă o aplicație — de ce întrebarea despre preț vine prea devreme și ce contează cu adevărat înainte de dezvoltare

Aproape fiecare discuție cu un antreprenor nou începe la fel. „Salut, am o idee. Cât m-ar costa o aplicație?”

E o întrebare legitimă. Omul are un buget, are o idee și vrea un număr ca să știe dacă poate începe. Problema e că întrebarea asta seamănă cu „cât costă o casă?”. Răspunsul corect e mereu altul: depinde câte camere, pe ce teren, cu ce fundație, pentru cine, și — cel mai important — ai verificat dacă cineva vrea să locuiască acolo?

După ani de proiecte livrate, am ajuns la o concluzie inconfortabilă: prețul de dezvoltare e rareori motivul pentru care un produs digital eșuează. Ce omoară produsele e tot ce se întâmplă în jurul codului. Și există date solide care spun asta.

1. Ce spun datele: capitalul e cauza morții, nu boala

CB Insights a analizat, în raportul publicat în martie 2026, 431 de startup-uri finanțate cu capital de risc care s-au închis din 2023 încoace. Cauza cea mai frecvent invocată — „am rămas fără bani” — apare în 70% din cazuri. Dar analiștii lor sunt foarte expliciți: asta e cauza decesului, nu boala.

Motivele reale, cele care explică de ce s-au terminat banii, arată altfel:

CauzăFrecvență
Product-market fit slab43%
Timing greșit / condiții de piață29%
Unit economics nesustenabile19%

Companiile din analiză strânseseră împreună 17,5 miliarde de dolari înainte să moară. Mediana per companie: 11 milioane. Deci nu banii au lipsit. A lipsit potrivirea dintre produs și piață.

Și încă un detaliu care ar trebui să pună pe gânduri orice fondator: două treimi dintre eșecurile de product-market fit au fost companii early-stage care nu au găsit niciodată o piață — dar 20 dintre ele ajunseseră deja la runda Series B. Poți strânge milioane și tot să construiești ceva ce nimeni nu cere.

Marc Andreessen a formulat asta cel mai clar încă din 2007, într-un eseu care a devenit între timp lectură obligatorie: „The only thing that matters is getting to product/market fit.” Singurul lucru care contează e să ajungi la product-market fit. Restul — stack, design, echipă, buget — sunt variabile subordonate.

2. Întrebarea „cât costă” presupune că produsul e deja definit

Când cineva cere un preț pentru „o aplicație”, presupune implicit că știe ce trebuie construit. În 90% din cazuri, nu știe. Și nu e o critică — e normal. Ideea trăiește în capul fondatorului sub formă de intuiție, nu de specificație.

Diferența dintre o ofertă de 8.000 EUR și una de 60.000 EUR pentru „aceeași aplicație” nu e lăcomia furnizorului. E faptul că cei doi au înțeles două produse complet diferite din același brief de trei paragrafe.

Un studiu de caz din propria noastră experiență: un client venise cu „un marketplace simplu, ca OLX, dar pentru nișa mea”. După două sesiuni de discovery, „simplu” însemna: verificare identitate, escrow pentru plăți, sistem de dispute, rating bidirecțional, chat, notificări push și un panou de moderare. Adică nu un proiect de 6 săptămâni, ci de 6 luni. Nimeni nu mințea. Pur și simplu cuvântul „simplu” nu are aceeași semnificație de-o parte și de alta a mesei.

De aceea, prima livrare într-un proiect serios nu e cod. E un document.

Iar dacă vrei totuși repere concrete de buget, am publicat un ghid de prețuri pentru aplicații mobile în 2026, cu intervale pe niveluri de complexitate.

3. Market research: linia cea mai ieftină din buget și prima tăiată

Structura tipică de costuri într-un proiect de aplicație arată cam așa: discovery și research 10–15%, design UI/UX 20–25%, dezvoltare 40–55%, QA și testare 15–20%.

Ghiciți ce se taie primul când bugetul e strâns? Exact: primele 10–15%. Partea care decide dacă restul de 85% are vreun sens.

Discovery-ul nu înseamnă un PowerPoint cu „piața globală de X valorează Y miliarde”. Înseamnă lucruri concrete și ieftine:

  • 15–20 de interviuri cu oameni din publicul-țintă, în care nu îți prezinți ideea, ci întrebi cum rezolvă azi problema. Steve Blank numește asta „get out of the building” — niciun răspuns nu se află în birou.
  • O hartă a concurenței reale, inclusiv soluțiile improvizate: Excel, WhatsApp, un caiet. Cel mai puternic concurent al tău nu e o altă aplicație, ci obiceiul.
  • Un test de disponibilitate de plată, înainte de linia unu de cod. O landing page, o listă de așteptare, o precomandă.

Costul acestei etape? Câteva mii de euro. Costul evitat? Vezi tabelul din secțiunea 1.

Aici merită amintit și mitul cu „faster horses” atribuit lui Henry Ford — folosit constant ca scuză pentru a nu vorbi cu utilizatorii. Citatul nu apare documentat nicăieri în scrierile lui Ford. Iar chiar dacă ar fi real, spune altceva decât se pretinde: oamenii nu îți vor descrie soluția, dar îți vor descrie perfect problema. Treaba ta e să asculți problema, nu să ceri soluția.

Market research este cea mai ieftină parte a proiectului și, de multe ori, prima tăiată din buget

4. UX/UI nu înseamnă „să arate frumos”

Cea mai scumpă confuzie din industrie: designul tratat ca strat cosmetic aplicat la final.

McKinsey a urmărit 300 de companii publice timp de cinci ani și a construit un indice al maturității în design. Companiile din primul sfert au avut o creștere a veniturilor cu 32 de puncte procentuale mai mare și un randament total pentru acționari cu 56 de puncte procentuale mai mare decât media din industria lor.

Circulă și cifra Forrester — fiecare dolar investit în UX ar aduce înapoi 100 de dolari, adică un ROI de 9.900%. O folosim cu prudență, pentru că e o cercetare veche și extrapolată agresiv în marketing. Direcția însă e confirmată de comportamentul real al utilizatorilor, iar acolo cifrele sunt brutale.

Benchmark-urile globale de retenție pentru aplicații mobile arată aproximativ 26% în Ziua 1, 13% în Ziua 7 și 7% în Ziua 30. Alte analize plasează mediana la Ziua 30 chiar la 4%, iar circa un sfert dintre utilizatori abandonează aplicația după o singură utilizare.

Traduceți asta în bani: dacă plătiți 2 EUR pe instalare și pierdeți 93% dintre utilizatori în 30 de zile, costul real per utilizator activ nu e 2 EUR, ci aproape 30 EUR. Nu ai o problemă de marketing. Ai o problemă de onboarding, adică de UX.

Steve Jobs a rezumat-o în cinci cuvinte, iar propoziția rămâne cel mai bun filtru pentru orice discuție despre design: „Design is how it works.”

5. Fiecare feature în plus e o datorie, nu un activ

Aici e locul unde bugetele mor cel mai discret.

Pendo a analizat datele de utilizare din 615 conturi de produse software și a găsit un tipar constant: aproximativ 80% dintre funcționalități sunt rar sau niciodată folosite, iar 12% dintre ele generează 80% din volumul zilnic de utilizare. Companiile de software listate public investiseră, prin extrapolare, până la 29,5 miliarde de dolari în funcționalități pe care nu le atinge nimeni.

Cifra mai veche a Standish Group — 45% funcționalități niciodată folosite, 19% rar folosite, deci 64% — e din 2002 și a fost criticată metodologic. Dar, semnificativ, niciun studiu ulterior la scară mare nu a produs un rezultat substanțial diferit.

Ce înseamnă asta pentru oferta pe care o primești? Că din lista ta de 40 de funcționalități, probabil 8 contează. Iar dacă furnizorul le cotează pe toate 40 fără să pună o singură întrebare despre prioritizare, nu ți-a făcut o ofertă — ți-a făcut o factură.

Reid Hoffman, cofondator LinkedIn, are o regulă cunoscută: dacă nu ești ușor jenat de prima versiune a produsului, ai lansat prea târziu. Nu e un îndemn la neglijență. E un îndemn la a lăsa piața să decidă ce merită construit în continuare.

Fiecare funcționalitate în plus e și o datorie — aproximativ 80% dintre funcții sunt rar sau niciodată folosite

6. Testarea cu oameni reali: singurul moment în care afli adevărul

În industrie circulă intens „regula celor 100x”: un defect descoperit în faza de design costă 1, în implementare ~6,5, în testare ~15, iar în producție până la 100.

Sursa clasică — IBM Systems Sciences Institute — a fost contestată public: cercetătorul Laurent Bossavit a arătat că datele originale sunt fie inexistente, fie anterioare anilor ‘80. Menționăm asta tocmai pentru că un articol documentat nu e unul care citează impresionant, ci unul care spune și când o cifră e fragilă.

Ordinul de mărime rămâne însă susținut de surse independente. Consortium for Information & Software Quality estimează costul software-ului de proastă calitate doar în SUA la 2,41 trilioane de dolari anual, din care 260 de miliarde vin din proiecte eșuate.

Ce funcționează concret, la scara unui IMM:

  1. Prototip clicabil înainte de dezvoltare. Cinci utilizatori reali, o oră fiecare, task-uri concrete. Vei descoperi 70–80% dintre problemele majore de flux.
  2. Beta închis cu 20–30 de oameni din publicul-țintă, nu cu prieteni și familie. Prietenii îți spun că e frumos. Publicul-țintă îți spune că nu înțelege butonul.
  3. Analytics de la prima zi în producție. Nu poți repara ce nu măsori.

Regula noastră: dacă nu ai vorbit cu cel puțin 10 utilizatori între design și lansare, nu ai construit un produs. Ai construit o ipoteză scumpă.

7. Distribuția: partea pe care aproape nimeni nu o pune în buget

Există peste 4,1 milioane de aplicații în Google Play și App Store combinate, iar descoperibilitatea a devenit problema tehnică numărul unu. Analizele Adjust au estimat, la un moment dat, că aproximativ 90% dintre aplicațiile din App Store sunt „zombie” — invizibile organic, găsibile doar dacă le cauți numele exact.

Traducere: dacă planul tău de distribuție e „o punem în store”, planul tău de distribuție nu există.

Un buget realist alocă distribuției cel puțin cât alocă dezvoltării în primul an. Nu neapărat în reclame plătite — poate fi conținut, SEO, parteneriate, comunitate, presă de nișă. Dar trebuie să fie o linie în buget, cu un responsabil și cu obiective măsurabile.

Motoul Y Combinator — „make something people want” — funcționează în ambele sensuri: mai întâi construiește ce vor oamenii, apoi asigură-te că oamenii aceia află că există.

8. Comunicarea: variabila invizibilă care mișcă cel mai mult costul

Din experiența noastră cu 15+ dezvoltatori și zeci de proiecte, cel mai bun predictor al unui proiect livrat la timp nu e stack-ul, seniorii sau metodologia. E cât de repede răspunde clientul.

Un proiect cu feedback în 24 de ore merge de două ori mai repede decât unul identic cu feedback în 10 zile — pentru că echipa nu doar așteaptă, ci pierde contextul și trebuie să îl reconstruiască.

Trei lucruri care reduc costul mai mult decât orice negociere de tarif:

  • Un singur decident. Trei stakeholderi cu păreri divergente nu produc un produs mai bun, produc rescrieri.
  • Demo la fiecare două săptămâni, cu produsul rulând, nu cu screenshot-uri.
  • Un backlog prioritizat public, unde „nu acum” e un răspuns acceptabil și vizibil.

9. Lansarea nu e linia de sosire

Standardul din industrie pentru mentenanță e 15–25% din costul inițial, anual — servere, actualizări de OS, patch-uri de securitate, bug-uri, adaptări la schimbări de API. Iar în primul an după lansare, costurile pot ajunge chiar la 50% din investiția inițială, pentru că acolo se concentrează iterațiile bazate pe feedback real.

O aplicație de 40.000 EUR nu e un cost de 40.000 EUR. E un cost de 40.000 EUR plus 6.000–10.000 EUR pe an, pe termen nedefinit. Cine nu îți spune asta din prima discuție, fie nu știe, fie nu vrea să știi.

10. Consultanța tehnică nu înseamnă să răspunzi la întrebări. Înseamnă să le pui pe cele corecte.

După toate datele prezentate până acum, apare o concluzie care poate părea surprinzătoare.

Majoritatea proiectelor software nu eșuează pentru că echipa de dezvoltare nu știe să scrie cod. Și nici pentru că tehnologia aleasă este greșită.

Cele mai multe probleme apar mult mai devreme. Apar în momentul în care proiectul pornește de la presupuneri care nu au fost niciodată validate.

Acesta este, de fapt, rolul consultanței tehnice. Nu să spună dacă o idee este bună sau rea, ci să transforme o idee într-un plan care poate fi construit cu un risc cât mai mic.

Un consultant bun nu începe prin a vorbi despre tehnologii. Nu începe cu React, Flutter, Laravel sau Kubernetes. Începe cu întrebări. Și, de cele mai multe ori, răspunsurile la aceste întrebări schimbă produsul înainte să fie scrisă prima linie de cod.

Întrebările care economisesc cel mai mult

În etapa de discovery există câteva întrebări care valorează mai mult decât orice estimare de buget. De exemplu:

  • Care este problema reală pe care încercăm să o rezolvăm?
  • Cine are această problemă și cât de des apare?
  • Cum o rezolvă oamenii în prezent?
  • De ce ar renunța la soluția actuală?
  • Care este funcționalitatea fără de care produsul nu are valoare?
  • Ce putem elimina fără să afectăm experiența utilizatorului?
  • Cum vom măsura dacă produsul are succes după lansare?
  • Ce presupuneri putem valida înainte să investim în dezvoltare?

La prima vedere, aceste întrebări nu par spectaculoase. Nu produc un prototip. Nu generează o aplicație. Nu pot fi prezentate într-un demo.

Dar foarte des sunt întrebările care economisesc cele mai multe luni de muncă și cele mai multe zeci de mii de euro.

Cea mai ieftină modificare este cea pe care nu mai trebuie să o faci

Există un principiu simplu în dezvoltarea software: cu cât o decizie este luată mai târziu, cu atât costul modificării ei este mai mare.

Dacă schimbi o idee în timpul unui workshop, costul este aproape zero. Dacă aceeași schimbare apare după două luni de dezvoltare, înseamnă redesign, rescriere de cod, noi teste și întârzieri. Dacă apare după lansare, înseamnă și costuri tehnice, și utilizatori nemulțumiți.

Acesta este motivul pentru care cele mai valoroase proiecte nu sunt cele în care se scrie cel mai mult cod. Sunt cele în care se evită construirea lucrurilor greșite.

O echipă bună nu spune doar „da”

Uneori, cel mai valoros răspuns pe care îl poate primi un client este: „Nu credem că această funcționalitate trebuie construită acum.” Sau chiar: „Nu credem că aceasta este problema care trebuie rezolvată.”

Poate părea contraintuitiv. Dar o echipă care acceptă orice cerință fără să o pună sub semnul întrebării nu oferă consultanță. Execută.

Consultanța începe exact în momentul în care apar întrebările dificile. De ce? Pentru cine? Ce valoare aduce? Cum vom măsura rezultatul?

Dacă răspunsurile nu sunt clare, dezvoltarea nu elimină incertitudinea. Doar o transformă în cod.

Rolul unei echipe tehnice moderne

În urmă cu zece ani, principalul avantaj al unei agenții era capacitatea de a construi aplicații complexe. Astăzi, instrumentele AI au redus considerabil timpul necesar dezvoltării.

Asta înseamnă că adevărata valoare nu mai este doar viteza de implementare. Este capacitatea de a lua deciziile corecte înainte ca implementarea să înceapă.

Tehnologia poate accelera dezvoltarea. Nu poate decide ce merită dezvoltat. Aceasta rămâne o responsabilitate umană — și, probabil, cea mai importantă.

Consultanța tehnică nu înseamnă să răspunzi la întrebări, ci să pui întrebările corecte înainte de dezvoltare

Concluzie

La începutul acestui articol am pornit de la o întrebare pe care aproape orice antreprenor o pune: „Cât costă o aplicație?”

După toate datele analizate, răspunsul este, probabil, altul decât te-ai aștepta. Costul dezvoltării este doar o parte din investiție. Uneori nici măcar cea mai importantă.

Cele mai scumpe greșeli apar înainte de dezvoltare:

  • atunci când construiești un produs pentru o problemă insuficient înțeleasă;
  • atunci când adaugi funcționalități pe care nimeni nu le va folosi;
  • atunci când sari peste cercetarea utilizatorilor;
  • atunci când tratezi UX-ul ca pe un exercițiu de design, nu ca pe un proces de rezolvare a unei probleme;
  • sau atunci când lansezi fără să ai un plan prin care produsul să ajungă la oamenii pentru care a fost creat.

Consultanța tehnică nu elimină riscul. Nicio metodologie nu poate face asta. Dar poate reduce semnificativ numărul deciziilor luate pe baza presupunerilor. Iar într-un proiect software, acesta este unul dintre cele mai valoroase lucruri pe care le poți cumpăra.

La final, întrebarea nu mai este „Cât costă să dezvolt o aplicație?”, ci: „Ce decizii trebuie să luăm astăzi pentru ca investiția de mâine să aibă sens?”

Pentru că, în software, succesul nu este determinat de cât de repede începi să scrii cod. Este determinat de cât de bine înțelegi ce merită construit înainte să îl scrii.

Ideea principală: dezvoltarea software este o investiție, nu o achiziție. Iar cele mai bune investiții nu încep cu programarea — încep cu întrebările potrivite.

Surse