Cât costă o aplicație web la comandă în 2026 și pe ce plătești de fapt

Ceri trei oferte pentru „o aplicație de programări” și primești trei sume care nu seamănă între ele. De obicei nimeni nu greșește la calcul. Fiecare furnizor și-a imaginat altă aplicație.

Prețul unei aplicații la comandă nu se stabilește după numărul de ecrane sau după limbajul de programare. Se stabilește după ce trebuie să facă aplicația, pentru cine, cu ce date și ce se întâmplă când ceva nu merge. Mai jos sunt factorii care mută prețul, ce trebuie să conțină o ofertă ca să poți compara și costurile care apar după lansare.

Ce determină prețul

Numărul de fluxuri complete. Un flux este un drum de la început la sfârșit: o cerere devine ofertă aprobată, o programare ajunge în calendar și pleacă o confirmare, o comandă scade stocul. Fiecare flux adaugă ecrane, reguli, cazuri de eroare și teste. Este cel mai important factor de cost.

Rolurile și permisiunile. O aplicație folosită de un singur tip de utilizator e mai simplă decât una în care clientul, angajatul și managerul văd lucruri diferite. Fiecare rol înseamnă reguli de acces care trebuie construite și verificate.

Integrările. Legătura cu un sistem existent (facturare, ERP, plăți, curierat) poate fi un import dintr-un fișier sau o sincronizare prin API în ambele sensuri. A doua variantă costă mai mult. Trebuie tratate erorile, reîncercările și situațiile în care cele două sisteme nu mai sunt de acord.

Datele existente. Dacă pornești de la zero, nu există migrare. Dacă ai ani de date în Excel sau într-un program vechi, cineva trebuie să le curețe, să le potrivească și să le importe fără să piardă nimic.

Tipul de aplicație. O aplicație web responsive merge pe telefon, tabletă și calculator. Aplicațiile mobile native (din App Store și Google Play) înseamnă de obicei încă un proiect. Platformele cu mai multe organizații separate și abonamentele complexe sunt și ele etape separate.

Cerințele de funcționare. Cine are voie să vadă ce, cât de repede trebuie recuperate datele după o problemă, cine este anunțat când apare o eroare. Acestea nu se văd într-un demo, dar se plătesc la construcție.

Ce trebuie să conțină o ofertă corectă

O sumă fără scop scris nu poate fi comparată cu altă sumă. Cere ca oferta să includă:

• Scopul descris ca fluxuri, cu criterii de acceptare: ce trebuie să poată face un utilizator ca livrarea să fie considerată gata.
• Ce este inclus și ce nu. Lista lucrurilor excluse spune cel puțin la fel de mult ca lista celor incluse.
• Cine deține codul sursă și când îl primești.
• Ce se întâmplă după predare: o perioadă de corectare a defectelor și ce înseamnă un defect față de o funcție nouă.
• Costurile recurente: găzduire, servicii externe și mentenanță, estimate înainte de semnare.
• Calendarul și ce depinde de tine: accese, materiale, testare și aprobare.
• Plata legată de livrări, nu de ore consumate.

Costurile pe care le uiți

Prețul de construcție este doar o parte. După lansare apar:

• Găzduirea și serviciile externe. Serverele, baza de date, emailurile trimise și orice API plătit, inclusiv modelele AI, unde costul crește cu utilizarea.
• Mentenanța. Actualizări de securitate, ajustări după feedback și mici îmbunătățiri. Poate fi un abonament lunar sau intervenții la cerere, dar trebuie prevăzută.
• Timpul echipei tale. Cineva trebuie să explice procesul, să testeze cu date reale și să aprobe. O aplicație bună cere câteva ore de implicare reală pe săptămână, nu doar la final.

Un exemplu concret: cum arată prețul la noi

La PhantomTech, prima etapă are preț fix: Build Sprint, 30.000 lei (6.000 €) fără TVA. În această sumă construim un flux complet, cu până la două roluri și o integrare sau un import agreat. Îl publicăm pe un link privat de testare în 10 zile lucrătoare, socotite de la confirmarea scopului și primirea accesului și materialelor.

Ce primești:

• un atelier inițial, fluxul și ecranele principale, plus criterii de acceptare scrise;
• o aplicație web responsive, cu date salvate și acces de test;
• o rundă de revizii în scopul agreat (corectarea defectelor nu consumă această rundă);
• codul sursă, accesul la conturi, o prezentare înregistrată și instrucțiuni, după aprobare și plata integrală;
• 30 de zile de corectare a defectelor de la predarea aprobată.

Plata este 60% la rezervare și 40% la predarea aprobată. Se estimează separat fluxurile suplimentare, aplicațiile mobile native, platformele cu mai multe organizații, abonamentele complexe și migrările mari. Găzduirea, utilizarea API-urilor și mentenanța se estimează înainte de rezervare și se plătesc separat.

Pentru un produs mai mare, sprintul este prima parte utilizabilă, nu tot proiectul. Avantajul e că vezi software care funcționează înainte să decizi următoarea etapă. Detaliile sunt pe pagina Build Sprint și pe pagina de prețuri.

Cum reduci costul fără să reduci calitatea

• Începe cu fluxul care contează cel mai mult. Restul îl adaugi după ce primul e folosit.
• Import înainte de integrare. Un import dintr-un fișier poate valida procesul. Sincronizarea prin API poate veni când știi exact ce date circulă.
• Web responsive înainte de nativ. Pentru multe procese interne, o aplicație web bună pe telefon este suficientă.
• Stabilește regulile înainte de construcție. Cine aprobă, ce se întâmplă la anulare, ce date sunt obligatorii. Fiecare regulă descoperită la final costă mai mult decât una scrisă la început.

Întrebări de pus înainte să semnezi

1. Ce flux complet voi putea folosi la final și cum verificăm că e gata? 2. Ce nu este inclus în această ofertă? 3. Când primesc codul sursă și accesul la conturi? 4. Ce costuri lunare voi avea după lansare și cât sunt estimate? 5. Ce se întâmplă dacă găsesc un defect după predare? 6. Ce trebuie să fac eu și până când?

Dacă vrei să afli cât ar costa aplicația ta, programează un apel gratuit. Stabilim împreună fluxul și vedem dacă se potrivește într-un sprint sau are nevoie de mai multe etape.