# Software la comandă sau soft gata făcut: cum alegi

> Diferența reală dintre software la comandă și un instrument gata făcut nu e prețul de pornire, ci integrările, proprietatea datelor și costul pe trei ani.

URL: https://thenichesociety.ro/blog-software-la-comanda-sau-soft-gata-facut

Întrebarea nu e „construim de la zero sau cumpărăm un abonament”, ci care bucăți din procesul tău chiar merită cod nou. **Majoritatea firmelor nu au nevoie să înlocuiască instrumentul pe care-l folosesc deja, ci să construiască la comandă exact piesele care nu există în el — integrări, panouri interne, automatizări.** Restul e, de cele mai multe ori, cea mai scumpă cale de a reinventa ceva care există deja gata făcut.

## De ce „custom sau gata făcut” e întrebarea greșită

Ai un tabel Excel pentru comenzi, un modul de ERP pe care echipa îl ocolește pentru jumătate din pași, sau un SaaS care lasă pe dinafară exact partea care contează cel mai mult. La un moment dat, cineva zice „hai să ne facem un soft al nostru”. Întrebarea care urmează e, de obicei, greșit pusă: software la comandă sau soft gata făcut, ca o singură alegere pentru tot procesul.

De fapt, decizia se ia bucată cu bucată: ce parte din proces e prea comună ca să merite reinventată, și ce parte e specifică firmei tale, încât niciun pachet standard n-o acoperă. Articolul trece prin criteriile care contează, arată varianta hibridă pe care majoritatea firmelor o ratează, apoi un tabel de decizie și semnalele unei oferte de dezvoltare software nesigure.

## Primul criteriu: cât de standard e procesul și cât te diferențiază

Un test simplu din inginerie software ajută la decizie: dacă procesul pe care vrei să-l schimbi e ceva ce orice firmă din domeniul tău îl face la fel — contabilitate, onboarding, emiterea unei facturi — cumperi un instrument gata făcut și îți adaptezi procesul la el. Dacă procesul e chiar motivul pentru care clienții te aleg pe tine, partea aia merită cod scris special. Martin Fowler o spune direct: dacă procesul face parte din avantajul tău competitiv, construiești [software la comandă](https://thenichesociety.ro/software-personalizat); dacă nu, cumperi un pachet și te adaptezi la el.

Context: la nivelul UE, instrumentele gata făcute sunt deja regula — procentul firmelor cu ERP variază de la 41% la firmele mici până la 89% la cele mari, iar 53% din firmele din UE folosesc cel puțin un sistem ERP, CRM sau BI, conform Eurostat (2025). Nucleul standard e aproape mereu punctul de plecare corect; întrebarea utilă e ce lipsește din el, pentru tine.

30 de minute, gratuit. Îți spunem sincer dacă are sens.

## Al doilea criteriu: ce trebuie să vorbească cu ce

Puține instrumente cumpărate „de pe raft” vorbesc nativ cu tot ce ai deja în firmă. Un ERP ca SAGA sau SAP, un curier cu AWB-uri zilnice, sistemul RO e-Factura al ANAF — fiecare are un format propriu, iar un SaaS generic rareori le acoperă din cutie pe toate, mai ales pentru un flux specific unei firme românești. De cele mai multe ori, frecarea asta nu se rezolvă înlocuind nucleul, ci prin [aplicații web](https://thenichesociety.ro/aplicatii-web-saas) mici, dedicate, construite exact pentru puntea dintre sisteme.

Termenele nu sunt teoretice: raportarea B2B în RO e-Factura a devenit obligatorie din 1 ianuarie 2024, iar facturarea B2B prin același sistem din 1 iulie 2024, conform Ministerului Finanțelor. Indiferent dacă facturarea rămâne pe instrumentul cumpărat sau ajunge într-o piesă construită la comandă, integrarea cu e-Factura nu e opțională — e o cerință legală care se bifează oricum. Întrebarea de pus oricărui furnizor e simplă: cine actualizează integrarea când ANAF schimbă specificația?

## Al treilea criteriu: cine deține codul, infrastructura și datele

Când cumperi un abonament, datele tale stau de obicei în formatul și pe infrastructura furnizorului. Cât timp relația merge bine, nu contează. Contează în ziua în care furnizorul își schimbă prețurile, e cumpărat de altcineva sau închide produsul — moment în care negociezi din poziția firmei care nu deține nimic din ce a construit. Înainte de semnare, cere în scris în ce format îți exporți datele și în cât timp le primești dacă pleci.

De aici și capcana personalizării agresive a unui pachet cumpărat. Thoughtworks atrage atenția că personalizarea unui software cumpărat aduce aceleași riscuri ca dezvoltarea de la zero — întârzieri, costuri neprevăzute, competențe care nu țin de activitatea de bază — dar fără avantajul de a deține, la final, codul. Fowler recomandă opusul: în loc să personalizezi nucleul cumpărat, construiești piese separate, conectate prin API, pe care le deții integral — exact principiul din spatele variantei hibride.

## Al patrulea criteriu: costul pe trei ani, nu prețul de pornire

Un abonament pare ieftin în prima lună. Pe trei ani, costul crește cu numărul de utilizatori, cu volumul de date și, aproape mereu, cu tarifele pentru exact excepțiile de care ai nevoie — un modul suplimentar, un plan superior, un add-on doar pentru fluxul tău. Un build la comandă costă mai mult la început și cere mentenanță după, dar curba lui e diferită: efortul mare e concentrat la început, nu se multiplică cu fiecare utilizator nou.

Nu există verdict universal — nici „cumpără mereu”, nici „construiește mereu”. Forrester descrie asta ca un pendul: firmele care merg constant într-o singură extremă pierd control sau viteză, în timp ce combinarea deliberată aduce rezultatul cel mai stabil. Time to value contează la fel de mult ca prețul — un instrument cumpărat e aproape mereu mai rapid de pus în funcțiune decât un build de la zero, motiv în plus să nu arunci nucleul.

## Varianta hibridă: nucleul rămâne, piesele lipsă se construiesc la comandă

Discuția „custom sau gata făcut” se blochează pentru că e pusă ca alegere unică, pentru tot sistemul. Varianta hibridă — păstrezi nucleul standard și construiești la comandă doar piesele care lipsesc — e varianta la care ajung des firmele care analizează costul pe termen lung, nu doar prețul de pornire. Piesele construite în jur sunt de obicei trei: integrări, panouri interne de administrare și automatizări.

[AutosWorld](https://thenichesociety.ro/studii-de-caz/autosworld) e un exemplu concret, încă în etapă de lansare: un magazin online construit pe WooCommerce, cu platforma standard neatinsă. Ce se construiește la comandă e panoul de administrare din spate — dashboard, editare rapidă de produse, câmpuri proprii pentru furnizor și marjă, calculată automat. După autentificare, echipa ajunge direct în panoul ei, nu în WordPress, ca operarea zilnică a stocului să nu depindă de cineva din afară. Catalogul de 1.611 produse a fost verificat unul câte unul față de magazinul vechi, iar factura și AWB-ul se generează automat la fiecare comandă.

[Tchibo GAME ON](https://thenichesociety.ro/studii-de-caz/tchibo-gameon) arată situația opusă — procesul chiar e produsul. Campania cerea încărcare de bonuri fiscale de pe telefon, validare automată, reguli antifraudă împotriva bonurilor duplicate și un dashboard pentru echipă, cu participări, statusuri și export. Niciun instrument gata făcut nu acoperea combinația asta, așa că platforma a fost construită integral la comandă, de The Niche Society. Diferența față de AutosWorld nu e de calitate, e de tip de proces.

## Tabelul de decizie: ce recomandăm, în funcție de situație

Criteriile de mai sus dau un răspuns diferit pentru fiecare firmă, așa că tabelul de mai jos strânge situațiile frecvente și recomandarea potrivită fiecăreia. Citește-l pe bucăți de proces, nu pentru firmă în ansamblu: aceeași firmă poate avea un rând pentru facturare, altul pentru comenzi și altul pentru raportarea internă. Dacă te regăsești pe mai multe rânduri deodată, ești aproape sigur în zona variantei hibride.

Cele două proiecte descrise mai sus cad pe rânduri diferite ale tabelului. AutosWorld e pe rândul al patrulea: platforma standard rămâne, iar panoul de administrare se construiește la comandă. Tchibo GAME ON e pe rândul al treilea: procesul era chiar produsul, deci s-a construit tot. Dacă ești pe ultimul rând, nu e o problemă: e motivul pentru care primul pas, la noi, e un discovery scris, nu o ofertă de cod.

| Situație | Recomandare | De ce |
|---|---|---|
| Proces identic în orice firmă din domeniu | Cumperi instrumentul gata făcut | Nimeni nu câștigă reinventând un proces standardizat |
| Echipa pierde timp copiind date manual către alt sistem | Construiești o integrare la comandă peste nucleu | Problema e la granița dintre sisteme, nu în nucleu |
| Procesul e motivul pentru care te aleg clienții, nu concurența | Construiești software la comandă pentru acea bucată | Un pachet standard te aduce la nivelul pieței |
| Ai nevoie de back-office simplu peste o platformă standard (ex. magazin online) | Păstrezi nucleul, adaugi un panou construit la comandă | Nucleul rămâne ușor de actualizat |
| Nu știi încă ce proces vrei să automatizezi | Începi cu un discovery scris, nu o comandă de cod | Un scop greșit costă mai mult decât o lună de analiză |

## Cum arată un prim build serios — și ce urmărești într-o ofertă

Un prim build serios nu începe cu cod, ci cu un discovery scurt încheiat într-un document: ce se construiește, ce nu, cum arată integrările și cine face ce. Prima lansare e mică, deliberat — un singur flux, până la capăt. Codul și infrastructura stau, din prima zi, pe contul firmei client. La noi, discovery-ul e scurt și plătit, prețul fix vine după el, pe scopul scris, iar dacă te oprești acolo, raportul rămâne al tău.

Mentenanța nu se oprește la lansare: dependințele îmbătrânesc, integrările se pot rupe când ERP-ul sau specificația e-Factura se schimbă, iar patch-urile de securitate nu sunt opționale. Un software „uitat” doi-trei ani devine, tăcut, un risc — bugetul de mentenanță merită discutat din prima ofertă. Cere să vezi în ofertă cine repară o integrare ruptă, cum se anunță o problemă și cum primești codul și documentația dacă schimbi furnizorul.

- 01**Preț fix înainte de orice discovery** efortul a fost ghicit, nu văzut
- 02**Scop doar în discuții verbale, nu scris** neînțelegerile ies la iveală abia la livrare
- 03**Codul rămâne pe contul furnizorului** fără acces, ești legat de el pe termen nelimitat
- 04**Lansare unică, cu tot dintr-o dată** problemele ies la iveală prea târziu
- 05**Nicio discuție despre ce urmează după lansare** prima problemă devine urgență, nu sarcină planificată

## Surse și lecturi.

- 01[Eurostat — E-business software usage in EU enterprises (2025)](https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20260520-1)
- 02[Ministerul Finanțelor — RO e-Factura, prezentare oficială](https://mfinante.gov.ro/en/web/efactura)
- 03[Martin Fowler — Package Customization](https://martinfowler.com/bliki/PackageCustomization.html)
- 04[Thoughtworks — The Buy versus Build Shift: Issues With Buying Software](https://www.thoughtworks.com/insights/blog/buy-versus-build-shift-issues-buying-software)
- 05[Forrester — The ROI Pendulum: Build vs. Buy in the Age of AI](https://www.forrester.com/blogs/the-roi-pendulum-build-vs-buy-in-the-age-of-ai/)
30 de minute, gratuit. Îți spunem sincer dacă are sens.

## Întrebări frecvente

### Când merită să construiești software la comandă în loc să cumperi un instrument gata făcut?

Când procesul e motivul pentru care clienții te aleg pe tine, nu pe un concurent, sau când nicio combinație de instrumente de pe piață nu acoperă fluxul exact de care ai nevoie. Pentru tot ce e comun în domeniul tău, de obicei e mai ieftin să cumperi și să-ți adaptezi procesul.

### Ce înseamnă varianta hibridă și de ce o ratează majoritatea firmelor?

Să păstrezi instrumentul standard pe care-l folosești deja și să construiești la comandă doar piesele care lipsesc — integrări, panouri interne, automatizări. E ratată des pentru că discuția pornește ca alegere unică între „tot cumpărat” și „tot construit”, când decizia se ia separat, pe bucăți.

### Cum recunosc o ofertă serioasă de dezvoltare software la comandă?

Pornește cu un discovery și un scop scris, nu cu un preț fix dat din prima discuție. Propune o primă lansare mică, nu un „big bang” cu tot ce s-a imaginat vreodată, și lasă codul pe contul firmei tale de la prima zi.

### Cine ar trebui să dețină codul și infrastructura la un proiect de software la comandă?

Firma client, nu agenția care construiește. Codul stă pe contul organizației tale, infrastructura pe contul tău de cloud, chiar dacă agenția administrează zilnic. Așa poți schimba furnizorul oricând, fără să pierzi ce ai construit.

### Cum se stabilește prețul unui software la comandă?

După un discovery scurt, plătit, încheiat cu un document de scop: ce se construiește, ce nu și ce integrări intră. Prețul fix se dă pe acel scop scris, nu pe o estimare din prima discuție. Dacă te oprești după discovery, raportul rămâne al tău.

### Se poate lega o aplicație la comandă de SAGA, SAP sau e-Factura?

De obicei da, prin API sau prin formatele de import și export pe care programul le acceptă deja, fără să modifici nucleul. Ce expune concret versiunea ta se verifică în discovery. Pentru e-Factura, integrarea urmează specificația publicată de ANAF.

### Hai să vedem ce se poate automatiza la tine.

O sesiune gratuită de 30 de minute: îți spunem ce se poate automatiza, cât durează și cât costă, cu preț fix după discovery.

Răspundem în aceeași zi lucrătoare.