Cât durează cu adevărat să construiești o aplicație. Adevărul.

„Livrăm în 8 săptămâni." Toată lumea zice asta. Toată lumea livrează în 14 săptămâni. Asta e diferența dintre quote și realitate.

Un founder cu MVP fitness a primit promisiunea „MVP în 8 săptămâni" la 4 quote-uri diferite. Niciuna nu a livrat în 8 săptămâni. Cea mai rapidă: 13 săptămâni. Cea mai lentă: 26 săptămâni. Promisiune încălcată la toate 4.

De ce? Pentru că „8 săptămâni" e quote de marketing. Realitatea include: review-uri la design, schimbări de scope, integrări care eșuează la prima încercare, app store rejection, bug-uri găsite în testare. Toate astea nu sunt în quote. Ar trebui să fie.

Defalcarea sinceră: ce ia timp și de ce

Un MVP cu 5 features (auth, listă, detail, profil, search) împărțit pe faze:

Săptămâna 1-2: Discovery + Design. User stories, flow-uri, wireframe, design system, mockups Figma. Fără asta, scrii cod în orb. Realist: 60-100 ore. Studio bun: 1,5-2 săptămâni.

Săptămâna 3-4: Setup tehnic + arhitectură. Stack decis, repo creat, CI/CD, environment-uri (dev/staging/prod), autentificare integrată, baza de date schema. Realist: 40-80 ore. Săptămână 1-2 în paralel cu design dacă echipa e mare.

Săptămâna 5-9: Build features. Aici scrie codul real. 5 features × 30-50 ore fiecare = 150-250 ore. Echipă 2 oameni: 4-5 săptămâni. Echipă 1 om: 7-8 săptămâni.

Săptămâna 10-11: Testare + bug fix. Testare manuală, smoke test pe device-uri reale (iOS 14+, Android 9+), edge cases, performance. Realist: 60-100 ore + bug fix (20-40% din timpul build-ului).

Săptămâna 12-13: App Store + Play Store submission. Apple submission durează 24-72h, dar 30-40% din apps sunt rejected prima oară (motive: privacy policy, payment, IAP, copyright). Resubmit + 24-72h. Play Store mai relax, dar mid-tier review 7 zile.

Săptămâna 14-22: Live + iterație post-launch. Bug-uri în producție pe care testarea nu le-a prins (pattern Apple: 50-100 utilizatori scot la lumină probleme noi), feedback prim val utilizatori, mici fix-uri urgente. Buffer realist între săptămânile 14 și 22, depinde de complexitatea integrărilor și viteza echipei.

Total realist: 14-22 săptămâni pentru MVP cu 5 features cu echipă de 2 oameni. Range, nu cifră fixă.

De ce 8 săptămâni e o minciună

Quote-ul „8 săptămâni" rezultă din: 200 ore × 1 dev × 5 ore productive/zi = 8 săptămâni calendaristice. Pe hârtie.

Realitatea include:

• Review-uri client (40 ore așteptare per round, 3-5 round-uri = 4-7 zile pierdute)
• Design changes (20-40 ore în plus dacă feedback-ul e mid-build)
• App store rejection (3-7 zile per resubmit)
• Bug-uri găsite în testare (15-25% buffer minim)
• Concediu, weekend, vacanță (8 săptămâni calendaristice = 5,5-6 săptămâni efective)
• Integrări third-party care eșuează prima oară (Stripe webhook, Apple Pay, push notifications, tipic 10-20 ore extra fiecare)

Suma: 8 săptămâni „pe hârtie" devine 13-16 săptămâni real. Mereu. Cu orice studio.

Cine îți promite 8 săptămâni și livrează în 8 săptămâni: a) sub-livrat scope-ul, b) lucrat în weekend (te coace pe burnout team), c) livrat fără testare adecvată (vei plăti în bug-uri post-launch).

ÎNAINTE vs DUPĂ: quote vs realitate per scope

Ce trebuie să întrebi înainte să accepti orice timeline

Înainte să semnezi un contract cu „livrare în X săptămâni", pune 5 întrebări concrete.

1. „Ce e inclus în săptămâna 0?"

Răspuns serios: discovery (5-10 ore call), wireframe + flow-uri (15-25 ore), design system (40-60 ore), Figma mockups (40-80 ore), arhitectură tehnică decisă în scris.

Răspuns aiurea: „intrăm direct în build din ziua 1".

Cine sare peste discovery scrie cod care va trebui rescris.

2. „Câte round-uri de feedback include quote-ul?"

Răspuns serios: 3-5 round-uri specificate în SOW, fiecare cu deadline de răspuns client (48-72h). Schimbări mari = change request scris.

Răspuns aiurea: „nelimitat".

Nelimitat = haos. Va deveni 12 round-uri și încă nu e gata.

3. „Ce echipă e alocată proiectului?"

Răspuns serios: 1 PM, 1-2 dev, 1 designer, alocați procentual (50-80% din timp). Nume, CV-uri, GitHub.

Răspuns aiurea: „avem o echipă de experți".

Cine nu îți spune nume = nu există echipă, există un freelancer cu sub-contractor.

4. „Ce se întâmplă dacă apare scope creep?"

Răspuns serios: change request scris cu estimare ore + preț + impact pe timeline înainte de muncă. Modificări mici (sub 2h) gratis. Modificări mari = SOW addendum semnat.

Răspuns aiurea: „rezolvăm pe parcurs".

„Pe parcurs" = factură cu 40% peste quote la final.

5. „Care e penalizarea pentru întârziere?"

Răspuns serios: discount procentual din factură per săptămână întârziere (3-5% tipic) sau livrare la dată specifică sau credit pentru următorul proiect.

Răspuns aiurea: „nu se aplică, depinde".

Cine nu acceptă penalizare nu îți respectă timeline-ul.

Studiu de caz tipic: fitness MVP cu 3 quote-uri comparate

Un founder a comparat 3 quote-uri pentru același MVP de 5 features.

Quote A: „6 săptămâni, 12.000 EUR". Acceptat. Livrare reală: 22 săptămâni. Cost final cu scope creep: în jur de 18.000 EUR.

Quote B: „14 săptămâni, 18.000 EUR cu 5% discount per săptămână întârziere". Respins ca „prea lung".

Quote C: „10 săptămâni, 25.000 EUR, fără penalizare". Respins ca „prea scump".

În retrospectivă, quote-ul B era singurul realist. Studio-ul ar fi livrat în 14-16 săptămâni cu penalizare contractuală reală. Cost total: 18.000 EUR fix.

În schimb, founder-ul a plătit aceeași sumă pentru ceva ce a durat 22 săptămâni și o frustrare de 5 luni.

Diferența reală: nu prețul. Onestitatea timeline-ului.

Quote-ul scurt fără penalizare e aproape mereu mai scump decât quote-ul lung cu penalizare. Pentru că realitatea își găsește calea.

Plan de acțiune pentru următorul timeline pe care îl primești

1. Cere breakdown pe faze. Discovery, design, build, testare, app store, post-launch. Fiecare cu ore alocate. Total trebuie să se potrivească cu rate-ul orar declarat.
2. Adaugă 30% buffer mintal. Dacă quote-ul zice 8 săptămâni, planifică pentru 11. Dacă zice 12, planifică pentru 16.
3. Cere penalizare contractuală în SOW. 3-5% discount per săptămână întârziere. Dacă studio-ul refuză, nu crede în propriul timeline.
4. Verifică cu 2 clienți existenți. „A livrat la timp? Cât a fost diferența între quote și real?". Răspunsul lor e prediction-ul tău.
5. Pune milestone-uri intermediare. Săptămâna 4 = design final aprobat. Săptămâna 8 = 50% features funcționale. Săptămâna 12 = staging build complet. Dacă nu se ține de milestone-uri intermediare, nu va ține nici de final.

Lecția finală

Aplicația ta nu va fi gata în 8 săptămâni. Niciodată. Nu pentru că dezvoltatorul e leneș, ci pentru că realitatea include design, feedback, app store, bug-uri, integrări care eșuează.

Acceptă timeline realist (14-22 săptămâni pentru MVP serios) sau acceptă că vei fi mințit. Nu există a treia variantă.

Acum: scoate ultimul quote pe care l-ai primit. Verifică dacă include breakdown pe faze. Dacă nu, e quote de marketing, nu de inginerie. Cere breakdown sau pleci.