# Cât durează să construiești o aplicație (etape și termene reale)

> Published 2026-07-23 · Canonical: https://goodglyph.com/ro/blog/cat-dureaza-o-aplicatie

Prima versiune utilizabilă în câteva săptămâni, o aplicație completă în luni: benzile reale de timp, etapele prin care trece orice proiect, și factorii care lungesc sau scurtează drumul, inclusiv cei care depind de tine.

Răspunsul scurt, ca să nu-l ținem ostatic: o primă versiune utilizabilă a unei aplicații simple se construiește în câteva săptămâni, orientativ 4 până la 8. O aplicație completă, cu mai multe module, roluri și integrări, durează luni, de obicei 3 până la 6. Un produs complex, un SaaS cu plăți, conturi și aplicații pe mai multe platforme, trece ușor de jumătate de an. Sunt benzi orientative, nu promisiuni, și fiecare depinde de un factor pe care puțini îl anticipează: viteza cu care se iau deciziile, inclusiv ale tale.

Despre [cât costă o aplicație](https://goodglyph.com/ro/blog/cat-costa-o-aplicatie) am scris separat; costul și termenul se mișcă de altfel împreună, din același motiv: amândouă măsoară aceeași muncă. Aici despachetăm timpul: pe ce se duce, ce-l lungește și ce poți face să-l scurtezi fără să tai din calitate.

## De ce „depinde" e singurul răspuns cinstit la început

„Cât durează o aplicație?" seamănă cu „cât durează o casă?": depinde ce construiești. O garsonieră și o vilă cu trei etaje sunt amândouă „o casă". La aplicații, diferența o fac trei lucruri: câte funcționalități intră în prima versiune, câte sisteme externe trebuie legate (plăți, facturare, stocuri, alte servicii), și câți oameni diferiți o folosesc în roluri diferite. Oricine îți dă un termen ferm înainte să înțeleagă astea trei îți spune, de fapt, cât ar dura aplicația pe care o are el în cap, nu a ta.

## Etapele prin care trece orice proiect serios

Indiferent de mărime, drumul are aceleași patru etape, și fiecare are un rost precis:

1. **Discovery și fluxuri.** Se mapează problema, cine folosește aplicația și pe ce pași. Aici se decide ce intră în prima versiune și, la fel de important, ce nu intră. Orientativ: una-două săptămâni la proiecte mici, mai mult la cele complexe.
2. **Design UI/UX.** Interfața se desenează și se validează pe ecrane reale înainte să se scrie cod. E mult mai ieftin să muți un buton în design decât în aplicația construită. Orientativ: una până la trei săptămâni, în paralel parțial cu prima etapă.
3. **Dezvoltarea.** Construcția propriu-zisă, pe bucăți testabile, nu totul dintr-o bucată la final. La un proiect sănătos vezi versiuni intermediare pe care le poți încerca, ceea ce prinde neînțelegerile devreme. E etapa cea mai lungă: de la câteva săptămâni la câteva luni, în funcție de cele trei variabile de mai sus.
4. **Lansare și suport.** Punerea în producție, migrarea datelor unde există, instruirea oamenilor și perioada în care micile probleme reale ies la iveală. O săptămână-două active, apoi întreținere continuă.

Etapele nu sunt birocrație de agenție: fiecare există pentru că sărirea ei se plătește mai târziu, cu dobândă. [Am văzut asta și la instrumentele interne](https://goodglyph.com/ro/blog/de-la-excel-la-o-aplicatie-interna): proiectele care încep cu „hai direct la cod" sunt cele care se opresc la jumătate.

## Benzile de timp, pe tipuri de proiect

Ca să ai repere mai fine decât „săptămâni sau luni", uite cum arată benzile pe tipurile de proiecte pe care le întâlnim cel mai des:

- **Instrument intern pe un singur proces** (evidență, dashboard, câteva roluri): 4 până la 8 săptămâni până la folosirea zilnică. Cel mai previzibil tip de proiect, pentru că utilizatorii sunt în aceeași clădire cu deciziile.
- **Aplicație web pentru clienți** (portal, programări, cont de client): 2 până la 4 luni. Apare designul orientat spre public, care cere validare mai atentă, și de obicei o integrare-două.
- **Magazin sau platformă cu plăți:** 3 până la 6 luni. Plățile, facturarea și fluxurile de comandă aduc integrări și cazuri limită care nu se pot grăbi fără riscuri.
- **SaaS sau produs pe mai multe platforme:** de la 6 luni în sus, construit în versiuni. Aici nici nu mai vorbim de „un termen", ci de un ritm de livrare pe etape.

Benzile presupun un proiect condus disciplinat, cu decizii rapide. Cu ele în minte, ofertele devin comparabile: un termen mult sub bandă înseamnă de obicei că lipsește o etapă din listă, exact cum [un preț mult sub piață înseamnă că lipsesc straturi din lucrare](https://goodglyph.com/ro/blog/cat-costa-o-aplicatie).

## Ce lungește termenul (și cine controlează fiecare factor)

- **Integrările.** Fiecare sistem extern legat, plăți, facturare, curieri, aduce documentație de citit, cazuri limită și așteptat după terți. E factorul de întârziere cel mai subestimat.
- **Deciziile care stau.** Un proiect are zeci de întrebări mici: „păstrăm ambele variante de flux?", „cine primește notificarea?". Dacă răspunsurile vin în zile în loc de ore, săptămânile se adună. Ăsta e factorul care depinde de tine, și e mai mare decât pare.
- **Scopul care crește din mers.** „Dacă tot suntem aici, hai să adăugăm și...". Fiecare adăugare pare mică; suma lor e un alt proiect. Disciplina primei versiuni e cea care ține termenul.
- **Datele vechi.** Migrarea dintr-un sistem existent, sau [din fișiere Excel](https://goodglyph.com/ro/blog/de-la-excel-la-o-aplicatie-interna), durează mereu mai mult decât pare, pentru că datele vechi sunt mereu mai murdare decât par.

## Ce scurtează termenul, fără să taie din calitate

- **Prima versiune mică, pe o singură problemă.** MVP-ul, practic prima variantă utilizabilă, nu e o versiune de test aruncabilă: e nucleul corect construit al aplicației finale. Cu el ajungi în săptămâni la ceva folosibil, iar restul se adaugă pe o fundație dovedită. [Filozofia am despachetat-o în ghidul mare de aplicații](https://goodglyph.com/ro/blog/dezvoltare-aplicatii-mobile).
- **Un singur om care decide.** Comitetal se discută, singular se decide. Proiectele cu un decident clar merg vizibil mai repede decât cele în care fiecare răspuns așteaptă o ședință.
- **Web înainte de nativ, unde se poate.** O aplicație web ajunge la oameni fără magazine de aplicații și fără aprobări externe; varianta nativă se adaugă când chiar e nevoie de ea.
- **Procesul în etape, cu versiuni testabile.** Pare mai lent pe hârtie decât „ne apucăm direct", dar prinde problemele când costă ore, nu săptămâni.

## Partea de termen care e la tine

Merită spus separat, pentru că surprinde pe toată lumea la primul proiect: o parte din calendar e în curtea ta, nu a echipei de dezvoltare. Conținutul paginilor, logo-ul și materialele de brand, accesele la sistemele care se integrează, datele de migrat, omul care răspunde la întrebări: fiecare dintre ele e un punct în care proiectul fie curge, fie așteaptă. Lista scurtă pe care o dăm clienților înainte de start: cine decide, cine livrează conținutul și până când, cine dă accesele în prima săptămână, nu în a cincea. Proiectele în care lista asta e rezolvată din start țin termenul aproape de la sine.

## Un exemplu cu cifre rotunde

Un instrument intern pentru o firmă de servicii, evidență de comenzi cu trei roluri și un dashboard: o săptămână de discovery și fluxuri, două de design cu validare, patru-cinci de dezvoltare pe bucăți testabile, una de migrare a datelor și instruire. Total: în jur de două luni până la folosirea de zi cu zi, cu prima versiune în mâinile oamenilor mult mai devreme. Același proiect cu integrare de facturare și plăți: adaugă încă o lună. Cu un al doilea rând de păreri care schimbă fluxurile la mijlocul dezvoltării: încă una. Termenele nu se strică de obicei la cod; se strică la decizii. Ambele scenarii de mai sus sunt frecvente, iar diferența dintre ele n-a ținut niciodată de talentul echipei, ci de igiena deciziilor.

## O mențiune pentru cine reconstruiește, nu construiește

Dacă nu pornești de la zero, ci înlocuiești o aplicație existentă care șchioapătă, adaugă o marjă la orice bandă de mai sus. Motivul e practic: sistemul vechi trebuie să meargă în paralel cât se construiește cel nou, datele lui trebuie înțelese și mutate, iar oamenii obișnuiți cu vechiul flux au nevoie de o tranziție, nu de o schimbare peste noapte. Partea bună: discovery-ul e mai rapid și mai precis, pentru că procesul există deja și se vede exact ce doare. O reconstrucție bine condusă schimbă motoarele din mers, bucată cu bucată, fără ziua în care „oprim tot și trecem pe nou", care sună eficient și sfârșește rău.

## Recomandarea GOODGLYPH

Nu cumpăra un termen, cumpără un proces care ți-l arată pe drum. Un furnizor serios nu-ți promite „gata în 6 săptămâni" înainte de discovery; îți spune ce află în prima etapă, îți arată versiuni pe parcurs și îți spune devreme când ceva mișcă termenul, nu în ultima zi. Așa lucrăm și noi la [aplicațiile custom](https://goodglyph.com/ro/servicii/custom-apps): pornim de la procesul tău, construim întâi versiunea mică și o creștem pe dovezi. Dacă vrei un termen pentru proiectul tău concret, [scrie-ne](https://goodglyph.com/ro/servicii/custom-apps): după o discuție de discovery, cifra pe care o primești e una în care putem crede amândoi.

## Încheiere

O aplicație durează exact cât durează deciziile plus construcția, iar din cele două, construcția e partea previzibilă. Alege o primă versiune mică, ține deciziile aproape și lasă etapele să-și facă treaba: e cel mai scurt drum care nu se plătește de două ori.

## FAQ

### Cât durează un MVP?

Orientativ 4 până la 8 săptămâni pentru o primă versiune utilizabilă pe o problemă clară. MVP-ul nu e o schiță aruncabilă, e nucleul corect construit al aplicației finale.

### Cât durează o aplicație mobilă față de una web?

Varianta web ajunge de obicei mai repede la oameni: fără magazine de aplicații și aprobări externe. Nativul adaugă timp de dezvoltare și de publicare; de-asta recomandăm des web întâi, nativ când chiar e nevoie.

### Ce pot face eu ca proiectul să meargă mai repede?

Trei lucruri: un singur decident cu răspunsuri rapide, disciplina de a ține prima versiune mică, și materiale pregătite la timp (conținut, accese, date). Viteza deciziilor tale e parte din termen.

### De ce nu primesc un termen ferm de la început?

Pentru că înainte de discovery nimeni nu știe ce construiește: câte funcționalități, câte integrări, câte roluri. Un termen dat înainte de astea descrie alt proiect. După discovery, termenul devine o promisiune ținută.

### Ce se întâmplă dacă apar schimbări pe parcurs?

Se discută deschis: unele intră în versiunea curentă, altele se programează pentru următoarea. Ce stricăm termenul e schimbarea nespusă sau strecurată, nu schimbarea planificată.

### Lansarea înseamnă că proiectul s-a terminat?

Nu, înseamnă că a început să fie folosit. Primele săptămâni scot la iveală micile probleme reale, iar aplicația crește pe urmă în versiuni, pe dovezi din folosire, nu pe presupuneri.

## Related

- Related service: [Hai să-ți cotăm aplicația corect](https://goodglyph.com/ro/servicii/custom-apps)
- [Cât costă o aplicație (mobilă sau web)? Prețuri reale pentru afaceri](https://goodglyph.com/ro/blog/cat-costa-o-aplicatie)
- [Dezvoltarea unei aplicații mobile: de ce ai nevoie, de fapt](https://goodglyph.com/ro/blog/dezvoltare-aplicatii-mobile)
- [Portal de clienți sau CRM simplu: care dintre ele îți trebuie](https://goodglyph.com/ro/blog/portal-de-clienti-sau-crm)