Ce înseamnă un site custom, fără termeni tehnici

Doi antreprenori primesc două oferte cu același cuvânt pe ele: „custom”. Unul plătește pentru o temă cumpărată și modificată puțin, celălalt pentru cod scris special pentru fluxul lui de comenzi. Diferența de preț se vede imediat. Pe cea de conținut o afli abia după șase luni, când unul poate adăuga un modul nou și celălalt nu.

Cuvântul „custom” a ajuns să însemne aproape orice. Îl găsești în oferte de câteva sute de euro și în proiecte de zeci de mii, scris cu aceeași greutate. Furnizorul nu minte neapărat. Folosește un termen pe care nimeni nu s-a obosit să îl definească.

Partea proastă vine mai târziu, în ziua în care ceri o funcție nouă și primești răspunsul „nu se poate așa, ar trebui refăcut de la început”. Atunci afli ce ai cumpărat. Totul se poate explica în limbaj normal, cu exemple din firme mici și mijlocii din România, fără jargon de programator.

Ce cumperi, de fapt, când auzi cuvântul „custom”

Definiția simplă sună așa: un site custom se construiește în jurul felului în care lucrezi tu. Varianta opusă înseamnă să îți îndoi procesul până intră într-un șablon gândit pentru altcineva. Restul discuției ține de cât de departe merge fiecare furnizor cu ajustarea.

În practică, piața vinde trei lucruri diferite sub aceeași etichetă:

• temă cumpărată și populată, unde cadrul există deja și se schimbă doar culorile, pozele și textele, repede și la preț mic;
• temă modificată serios, cu design refăcut, câteva funcții adăugate prin module și uneori bucăți de cod scrise special (aici stă majoritatea ofertelor care poartă numele „custom”);
• aplicație web la comandă, unde logica de business se scrie de la zero, structura de date pornește de la procesul tău, iar panoul de administrare se face pe măsură.

Analogia cu haina ajută mai mult decât orice explicație tehnică. Poți lua un sacou de pe raft, poți duce sacoul la un croitor care îl strâmtează, sau poți merge la croitorul care taie materialul după măsurile tale. Toate trei sunt alegeri corecte. Doar că se potrivesc unor situații diferite și costă diferit.

Mai există o confuzie care produce facturi neplăcute: „design personalizat” nu înseamnă „funcționalitate personalizată”. Un designer poate desena ceva unic peste o structură complet standard. Arată bine în prezentare. Dar nu schimbă nimic din ce se întâmplă în spate când un client apasă butonul de comandă.

Există o întrebare care scurtează discuția: ce se întâmplă când vreau un modul nou peste un an? Dacă răspunsul sună a „vedem dacă găsim un modul potrivit”, cumperi o temă. Un răspuns de tipul „îl scriem în aceeași structură, cu aceleași reguli” înseamnă că plătești pentru cod.

Unde se rupe un site pe template față de unul personalizat

Temele rezolvă foarte bine cazurile comune, și asta trebuie spus fără snobism. Un site cu pagini de servicii, portofoliu, echipă și formular de contact nu are nevoie de cod scris de la zero. Aceleași nevoi apar la mii de firme, iar soluția a fost construită deja de nenumărate ori.

Ruptura apare în clipa în care firma ta are o regulă pe care restul pieței nu o are. Prețuri diferite pentru fiecare client, în funcție de contract. Aprobare pe două-trei niveluri înainte ca o comandă să intre în producție. Stocuri ținute separat pe filiale, cu transfer între ele, sau comisioane calculate pe fiecare agent de vânzări în locul unui procent din total.

De aici începe efectul de piesă peste piesă. Fiecare funcție nouă se rezolvă cu încă un modul, scris de altă echipă, actualizat în alt ritm, cu setări care se bat cap în cap. Limitările unei teme premium nu se văd în prima lună. Ies la iveală în luna a opta, când o actualizare strică pagina de finalizare a comenzii și nimeni nu poate spune exact din ce cauză.

Costul compromisului nu apare niciodată în ofertă, pentru că îl plătești în ore de om. Cineva copiază comenzile într-un fișier Excel, altcineva trimite manual confirmările, un al treilea verifică stocul la telefon. Trei ore pe zi înseamnă un salariu pe an. Și tu ai cumpărat „varianta ieftină”.

Un site personalizat pentru o firmă mică arată de multe ori banal la suprafață: șapte pagini, un formular, un catalog. În spate stă logica ta, scrisă curat, pe tehnologii mature, cum sunt framework-uri precum Laravel, cu mulți dezvoltatori disponibili în România, și nu invenții exotice pe care nu le mai preia nimeni peste doi ani. La BoringWeb, aplicațiile web la comandă le scriem în Laravel.

Semnale clare că ai nevoie de cod scris special pentru tine

Nu există un prag de cifră de afaceri de la care „ți se cuvine” cod propriu. Contează cât de complicat este procesul, iar mărimea firmei spune foarte puțin despre asta. Când ai nevoie de un site custom, semnalele vin din operațiuni, nu din design.

Ai un flux pe care nu îl mai are nimeni

Configurator de produs cu zeci de combinații. Calcul automat de ofertă în funcție de dimensiuni, material și distanță de livrare. Cerere care trece prin trei persoane înainte să devină comandă fermă. Astfel de fluxuri se pot imita cu formulare și e-mailuri, însă imitația se rupe la primul volum real.

Semnul clar apare în discuția cu furnizorul: îți explici procesul, iar el îți propune „hai să simplificăm”. Uneori simplificarea are sens și chiar te ajută. Alteori procesul tău este exact avantajul competitiv, iar simplificarea înseamnă să renunți la el ca să încapi într-un șablon.

Datele trebuie să circule în ambele sensuri

Integrarea cu ERP-ul și cu facturarea, într-un site serios, înseamnă stocuri actualizate aproape în timp real, comenzi care intră direct în programul de gestiune și documente generate fără intervenție umană. Un export la sfârșit de lună este cu totul altceva. Sincronizarea în ambele sensuri este punctul unde soluțiile la pachet cedează primele.

Adaugă aici cerințele de raportare care se mai schimbă de la un an la altul, inclusiv cele fiscale. O structură proprie se adaptează mai ușor decât un lanț de module cumpărate de la cinci furnizori diferiți, fiecare cu propriul calendar de actualizări.

Resursa limitată trebuie numărată exact

Un modul de programări online pare simplu până când resursa devine finită: o sală, patru medici, două utilaje, un singur șofer disponibil marțea. Suprapunerile nu se rezolvă cu un calendar frumos desenat, ci cu reguli scrise în cod și verificate la fiecare salvare. La o pensiune, resursa finită este camera. Am construit site-ul Pensiunii Alegria din Moieciu de Sus, cu camere și rezervări directe, iar acolo regula de bază sună simplu: aceeași cameră nu poate fi rezervată de două ori pentru aceeași noapte.

Fiecare client vede alt preț

Un magazin online cu prețuri B2B funcționează după alte legi decât unul obișnuit. Liste de prețuri pe grup de clienți, discounturi negociate în contract, comenzi minime, termene de plată diferite, catalog vizibil doar după autentificare. Când tariful depinde de cine se uită la ecran, ai ieșit din zona standard.

Câteva funcționalități cer aproape mereu cod propriu:

• raportări interne construite pe felul în care îți citești tu cifrele;
• roluri de utilizatori cu drepturi diferite pe secțiuni și pe date;
• automatizări între site, e-mail, curier și contabilitate;
• importuri repetate din fișiere primite de la furnizori, în formate care nu seamănă între ele.

Când nu merită un site custom și ce alegi în schimb

Cealaltă jumătate a discuției este mult mai liniștită. Multe firme nu au nevoie de cod scris de la zero. Să recunoști asta nu strică nimic.

Dacă ești la început și oferta ta încă se schimbă la două luni, banii stau mai bine în conținut, fotografii și promovare. O soluție simplă, precum un site de o singură pagină, te pune online în câteva zile și te lasă să testezi mesajul pe oameni reali. Peste un an îl înlocuiești fără regrete și fără bani pierduți.

A doua situație apare des în firmele mici: nu are cine să administreze conținutul. O structură cu module, roluri și fluxuri de aprobare devine povară când nimeni nu a mai intrat în panou de luni de zile. Complexitatea are sens doar dacă cineva o folosește săptămânal.

Regula bunului-simț: nu plăti pentru flexibilitate pe care nu o vei folosi în primii doi ani. Multe firme echilibrate aleg varianta de mijloc. Pornesc cu o soluție standard pentru partea de prezentare și adaugă modulul scris special exact acolo unde doare (configuratorul, calculul de ofertă, programările). Restul rămâne simplu și ieftin de întreținut.

Cât costă și cât durează o aplicație web la comandă

Costul dezvoltării unui site la comandă nu se calculează pe număr de pagini. Contează câte fluxuri, integrări și roluri de utilizatori are. Zece pagini de prezentare costă mai puțin decât un singur formular care vorbește corect cu programul de gestiune.

Ca ordin de mărime, fără să promitem cifre pe care nu le poate ști nimeni înainte de discuție: un site de prezentare solid stă în zona de câteva mii de lei, iar o aplicație web cu două-trei fluxuri proprii și o integrare pornește de obicei de la câteva mii de euro și urcă în funcție de câte sisteme atinge. La noi, site-ul de prezentare are preț fix, 1.986 RON cu TVA, și îl livrăm în maximum 10 zile lucrătoare după ce primim materialele.

La o aplicație lucrurile stau altfel. Orice preț ferm dat fără o conversație despre proces este marketing, nu estimare. Întrebările pe care ți le pune furnizorul decid bugetul real mai mult decât grila lui de tarife.

Ce urcă bugetul cel mai des

• integrări cu sisteme vechi, fără documentație și fără cineva care să le mai cunoască;
• migrarea datelor din fișiere adunate în ani, cu formate inconsecvente;
• cerințe de raportare apărute la jumătatea proiectului;
• validări care depind de decizii interne încă neluate.

Ce coboară bugetul și scurtează termenele

• livrarea pe etape, cu un prim set mic de funcții care intră efectiv în uz;
• o singură persoană din firma ta care decide rapid, fără comitet;
• conținutul și datele pregătite înainte de startul dezvoltării;
• acceptarea unor soluții deja existente pentru părțile banale.

Ce plătești după lansare

Un proiect la comandă nu se termină în ziua lansării. Pune în buget mentenanță lunară, actualizări de securitate și un pachet de ore de dezvoltare pentru cereri noi. Firmele care sar peste partea asta ajung, după doi ani, cu o aplicație pe care nu o mai actualizează nimeni.

Apoi vine clauza care valorează mai mult decât orice discount inițial: cine deține codul. Cere în scris proprietatea asupra surselor, acces la repository și o documentație minimă de instalare. Fără ele rămâi legat de un singur furnizor, pe termen nelimitat.

Întrebările pe care le pui înainte să semnezi

Un furnizor serios răspunde calm la întrebări incomode. Unul care se enervează îți arată deja cum va decurge proiectul. Ia întrebările astea cu tine la prima discuție.

• Ce se construiește de la zero și ce se ia din bibliotecă? Cere răspunsul pe componente, în scris. Să folosești module existente nu este o rușine. Problema apare când furnizorul le vinde drept dezvoltare la comandă.
• Cine poate prelua proiectul dacă ne despărțim? Tehnologii comune, cod documentat, structură standard. Dacă numele tehnologiei nu îți spune nimic, caută câți dezvoltatori din România lucrează cu ea.
• Cum administrez conținutul singur? Un panou clar, cu câmpuri pe înțelesul echipei tale, valorează mai mult decât orice efect de animație pe pagina principală.
• Ce se întâmplă la de cinci ori mai mult trafic? Performanța și găzduirea se discută la început, nu în ziua campaniei de Black Friday.
• Îmi arătați un proiect asemănător, funcțional? Cere un demo în care apeși butoane, nu doar capturi de ecran frumos aranjate într-o prezentare.

Răspunsurile la aceste cinci întrebări separă furnizorii mult mai bine decât prețul. Două oferte apropiate ca sumă pot ascunde lucruri complet diferite sub capotă.

Dacă nu ești sigur în ce categorie intri, o discuție de o jumătate de oră lămurește de obicei situația. Separăm ce se poate face cu o soluție standard de ce cere cod scris special și îți dăm o estimare pe scopul real, nu o ofertă tip trimisă tuturor. Pentru început, poți vedea felul în care lucrăm la un proiect, care spune mai mult decât orice grilă de prețuri.