BUZZSOFTWARE
SoluțiiPortofoliuTehnologiiDespre noiArticole
ENEnglishRORomână
Solicită ofertă
Disponibil pentru proiecte noi · Q2 2026
BUC · 44.43°N 26.10°E--:--:-- EET
// Pasul următor

Ai un produs de lansat?

Începe un proiect
BUZZSOFTWARE

Studio de software în București. Proiectăm. Construim. Lansăm. SaaS, mobile, e-commerce, AI.

Studio
Bucharest, RO
Mail
office@buzzsoftware.ro
Reply
< 24h

Companie

01
  • Despre noi
  • Soluții
  • Tehnologii
  • Procesul nostru
  • Contact

Resurse

02
  • Articole
  • Studii de caz
  • Întrebări frecvente
  • Solicită o ofertă

Legal

03
  • Politica de confidențialitate
  • Termeni și condiții
  • Hartă site

© 2026 BuzzSoftware · Toate drepturile rezervate.

Creat și implementat din Bucureștiv2026.05
BUZZSOFTWARE
Toate articolele
15 mai 2026·10 min de citit·Echipa BuzzSoftware

Cum angajezi o agenție de software custom în 2026

HiringAgenciesProcurementContractsSoftware Engineering

Cele mai multe procese de selecție a unei agenții o iau razna înainte de primul apel. Lista scurtă vine dintr-un motor de căutare care evidențiază agențiile bune la SEO, nu agențiile bune la inginerie. Pitch-deck-urile sună toate la fel — „echipă senior", „proces agile", „comunicare transparentă" — iar până realizezi că echipa alocată proiectului tău e formată din trei juniori și un arhitect part-time, ești la patru luni și €120k în engagement. Iată ce am căuta dacă am fi în partea de cumpărare.

Citește case studies, nu pagina de start

Paginile de start sunt scrise de marketeri. Case studies sunt scrise mai aproape de muncă. Caută detalii pe care un outsider nu le-ar putea inventa: ce versiune de framework, ce bază de date, ce target de deployment, ce s-a stricat în producție și cum s-a rezolvat. Un case study care numește „migrare AngularJS 1.5 → Vue 3 în 14 luni, cu strict mode TypeScript păstrat pe tot parcursul" e un semnal diferit de „am modernizat stack-ul de frontend".

Dacă fiecare case study sună a comunicat de presă, asta e echipa pe care o vei avea la proiect.

Întreabă cine scrie efectiv codul

Cea mai utilă întrebare într-un sales call: „Cine, nominal, va scrie codul? Pot vorbi cu el înainte să semnez?"

Agențiile sănătoase te vor pune într-un apel de 30 de minute cu inginerul care ți-ar conduce build-ul. Va fi vizibil senior. Va contrazice părți din spec-ul tău și va explica de ce. Va aduce constrângeri la care nu te gândiseși.

Agențiile care fac bait-and-switch — arhitect senior în pitch, echipă junior la livrare — vor evita întrebarea. Vor vorbi despre „echipa noastră" și „procesul nostru" și vor oferi referințe. Referințele se pot manevra. Un apel de 30 de minute cu inginerul real, nu.

Ce produce un discovery real

Un discovery real durează 2–4 săptămâni, e plătit și produce un document scris pe care îl poți citi cap-coadă. Ce conține:

  • Un model de domeniu — entitățile, câmpurile, relațiile. Desenat, nu doar descris.
  • O listă cu fiecare ecran sau endpoint cu un paragraf despre ce face.
  • O recomandare de stack cu rațiune — nu doar „Next.js", ci de ce Next.js peste Remix sau Astro pentru acest produs.
  • O hartă a integrărilor — fiecare sistem extern, în ce direcție curg datele, ce se întâmplă când unul cade.
  • Un registru de riscuri — cele 5–10 lucruri cele mai probabile să meargă prost, cu mitigarea pentru fiecare.

Dacă discovery e „gratuit" și produce un Figma și un Notion cu bullet-uri, ai primit un pitch deck, nu un plan.

Proprietatea codului: pune-o pe hârtie

Default-ul în custom software: codul îți aparține, integral. Asta înseamnă:

  • Un repository privat în contul organizației tale pe GitHub/GitLab, cu tine ca owner din ziua unu. Nu transfer la finalul contractului — la început.
  • Fiecare commit împins nominal, nu printr-un cont bot partajat.
  • Infrastructure-as-code pentru tot ce deploy-ează. Dacă îți configurează AWS-ul clic cu clic în consolă, nu deții cu adevărat infrastructura.
  • Niciun framework proprietar sau componente licențiate care te leagă. Dacă și-au construit propriul CMS, ar trebui să-l poți face fork și pleca fără să plătești taxe ulterioare.

Agențiile care rezistă oricăruia dintre punctele astea protejează un model de business care depinde de faptul că nu pleci. Ăsta e modelul. Pleacă.

Red flags care merită tratate ca deal-breakers

  • „Putem începe luni" — pentru un build de 12 luni. Înseamnă că nu au pipeline, deci sunt înfometați, deci vor spune da la tot ce intră în scope, iar calitatea va plăti.
  • Lipsă de leadership tehnic în sales call. Dacă nu poți vorbi cu persoana care ți-ar arhitectura build-ul în timpul pitch-ului, nu o vei vedea nici în timpul build-ului.
  • Cotații fără estimări. O cotație fix de €180k fără defalcare pe feature, săptămână sau rol e un număr, nu o estimare. Vei afla ce au planificat efectiv când ceva costă în plus.
  • „Echipă senior" fără bio-uri individuale. Inginerii senior reali au amprentă publică — GitHub, conferințe, blog, contribuții OSS. Dacă echipa e invizibilă online, probabil nu sunt oamenii din pitch.
  • Stack-uri de template pentru muncă non-template. „Folosim mereu [WordPress / Webflow / Bubble] pentru că e mai rapid" — ok pentru un landing page, semnal de alarmă pentru orice custom.

Reverse-reference check

Referințele furnizorilor sunt filtrate. Foștii clienți care au acceptat să dea referințe sunt cei care îi plac suficient. Asta îți spune un singur lucru.

Ce-ți spune mai mult: găsește un fost client care nu e pe lista de referințe. Caută pe LinkedIn proiectele vechi ale agenției, găsește CTO-ul sau product lead-ul de acum doi ani, trimite mesaj la rece. Întreabă: „I-ai mai angaja? Ce ai face altfel?" Răspunsul nefiltrat e cel care contează.

Ce ar trebui să spună contractul

  • Plată pe milestone-uri, nu hourly fără plafon. Hourly fără plafon aliniază incentivele spre prelungirea build-ului.
  • Test de acceptanță definit pentru fiecare milestone. „Flow funcțional de signup" nu e test de acceptanță. „Utilizatorul se înregistrează cu email + parolă, primește email de verificare în 30 de secunde, se loghează și vede dashboard gol" da.
  • IP assignment care se cesionează la plată, nu la final de contract. Dacă falimentează la mijlocul build-ului, păstrezi ce ai plătit.
  • O clauză specifică de handover. Ce primești în ziua unu post-launch? Acces la repo, runbook, credențiale de deployment, playbook de incidente, handoff pe on-call. Numește-le.
  • O clauză de sunset dacă încetezi plățile. Cele mai multe agenții îți vor menține infra-ul 30–90 de zile post-anulare cât migrezi. Contractul ar trebui să spună asta.

Pilotul de două săptămâni

Dacă engagement-ul depășește €50k, cere un pilot plătit de două săptămâni înainte de a te angaja la build-ul complet. Un discovery real, un fragment de software funcțional, un raport scris. Două săptămâni nu sunt suficiente pentru a simula competență — vei vedea cum gândește echipa, cum tratează o întrebare la care nu are răspuns, cum se citește codul lor la primul PR.

Costul a două săptămâni plătite e eroare de rotunjire pe un build de șase luni. Costul de a afla în luna patru că ai ales prost e tot engagement-ul.

Aduceți-ne partea complicată.

Trimiteți un paragraf despre ce vreți să construiți. Răspundem în 48 de ore cu scop, stack și preț.

Începeți un proiectSau vedeți ce facem →

Toate articolele

E-commerce custom vs Shopify în 2026: când construiești, când cumperi, când mergi hibrid

9 min de citit

Straturi de control agentic: tipare de fiabilitate în producție pentru agenții LLM

10 min de citit

RAG cu mai multe salturi la scară: în interiorul bazei de cunoștințe Opal a Teilor

11 min de citit