Ce plătești de fapt într-un proiect de dezvoltare web

Trei oferte pentru aceeași aplicație de programări ajung în aceeași săptămână. Prima are patru pagini cu module, termene și o listă cu ce nu intră în preț. A doua are un singur rând și o sumă rotundă. A treia nu are nicio cifră, doar o propunere pentru încă o discuție.

Majoritatea antreprenorilor aleg după sumă. Abia la jumătatea drumului descoperă că fiecare agenție a citit alt proiect în același brief. Sumele diferă pentru că promisiunile diferă, iar promisiunile devin vizibile doar când știi ce etape are un proiect de dezvoltare web și ce trebuie să primești concret la capătul fiecăreia.

Bugetul se poate dubla fără ca cineva să mintă. Se întâmplă în câteva momente precise. Pe toate le poți anticipa de la prima întâlnire.

Prima oră de discuție decide mai mult decât pare

Brief-ul pare o formalitate. Îți spui ideea, cealaltă parte dă din cap și toată lumea pleacă optimistă. În realitate, în prima oră se stabilește dacă proiectul are trei ecrane sau treizeci.

Contează mai puțin cât de frumos descrii ideea și mult mai mult cât de exact descrii o zi obișnuită din firmă. Cine primește comanda, unde o notează, cine sună clientul înapoi, ce document pleacă la final și în ce program se emite factura. O aplicație web la comandă copiază, în fond, un proces care există deja. Doar că acum procesul trăiește pe hârtie, într-un tabel Excel sau în capul unui singur om.

Întrebările bune din această oră sună plictisitor. Câți oameni vor avea cont? Clientul își face singur parola sau îi creezi tu accesul? Ce se întâmplă când o programare se anulează cu două ore înainte?

Fiecare răspuns adaugă sau scoate zile de muncă. Lista completă, cu explicația fiecărei întrebări, este în articolul despre întrebările care decid bugetul real al unui site la comandă.

La BoringWeb, proiectele personalizate pornesc exact de aici, de la o discuție de o oră. Prețul fix intră în contract abia după analiză.

Ordinea are un motiv simplu. Un preț dat înaintea analizei este o ghicitoare. Pe ghicitoare o plătește cineva mai târziu, de obicei clientul.

Analiza scrisă este documentul pe care îl vei deschide cel mai des

După discuție urmează un document. Unii îl numesc specificație, alții caiet de sarcini sau analiză funcțională. Numele contează puțin. Important este să fie scris în limba ta și să-l poți citi fără un programator lângă tine.

Într-o analiză bună vezi cine folosește aplicația și ce are voie să facă fiecare. Clientul vede doar comenzile lui. Angajatul vede toate comenzile zilei, iar managerul vede rapoartele și poate schimba prețurile. Tehnic, asta se numește sistem de roluri, iar fiecare rol în plus înseamnă ecrane și teste în plus.

Ce ar trebui să găsești în document

• fluxurile principale, descrise pas cu pas (clientul alege serviciul, alege ora, primește confirmare pe e-mail și SMS, angajatul vede programarea în calendar)
• integrările, cu numele exact al programelor folosite: procesatorul de plăți, curierul, programul de facturare, CRM-ul
• ce rămâne în afara proiectului, scris explicit
• etapele de livrare și ce poți testa la capătul fiecăreia
• pe numele cui sunt domeniul, hostingul și conturile la furnizori

Punctul al treilea este cel mai des sărit și cel mai scump. O frază de tipul „exportul către contabilitate nu intră în această etapă” scutește o ceartă de trei săptămâni. Fără ea, fiecare parte își amintește altceva despre ce s-a promis la cafea.

Analiza se plătește uneori separat. Este corect așa. Documentul rămâne al tău, iar cu el poți cere oferte și de la alte echipe, pe aceeași bază. O agenție care nu vrea să-ți predea analiza decât la pachet cu tot proiectul îți arată de pe acum cum va arăta colaborarea.

Restaurant, salon, service auto sau aplicație cu conturi de clienți

Cuvântul „site” acoperă lucruri care nu au aproape nimic în comun. Un restaurant de cartier și o platformă de programări pentru o rețea de service-uri pot ajunge la aceeași agenție cu același cuvânt în primul e-mail. Efortul dintre ele se măsoară în luni.

Restaurantul care vrea meniul și un buton de apel

Pentru un restaurant mic, nevoia reală este de obicei un meniu actualizat, programul, adresa pe hartă și telefonul la un deget distanță. Asta nu cere programare la comandă. Un site de prezentare acoperă totul. La BoringWeb îl livrăm la preț fix, 1.986 RON cu TVA, în maximum 10 zile lucrătoare de la primirea materialelor.

Situația se schimbă când același restaurant vrea comenzi online cu livrare proprie, zone de livrare cu taxe diferite și un ecran în bucătărie pe care apar comenzile noi. De aici începe dezvoltarea propriu-zisă. Ai nevoie de logică de comandă, notificări și un panou pentru personal.

Salonul care vrea să scape de telefoane în timpul lucrului

Salonul de înfrumusețare stă la mijloc. Un calendar simplu, în care clientul alege serviciul și ora, se poate adăuga peste un site de prezentare. La noi, calendarul de rezervări este unul dintre suplimentele cu preț clar.

Complexitatea apare când fiecare stilist are alt program și serviciile au durate diferite. Crește și mai mult când vrei avans la rezervare, ca să nu mai rămână scaune goale din cauza celor care nu mai vin.

Magazinul cu raft fizic care vrea să vândă și online

Pentru un magazin de retail cu stoc în gestiune, o singură întrebare decide aproape tot: stocul de pe site trebuie să fie identic cu cel din raft, în orice moment? Când răspunsul este da, proiectul include o legătură cu programul de gestiune. Costul depinde mult de cât de deschis este acel program. Unele oferă o interfață de conectare documentată, altele permit doar exporturi manuale sau cer un intermediar plătit lunar.

Magazinul online clasic, cu plată cu cardul, AWB generat automat la curier și factură emisă la confirmarea comenzii, are propriile reguli și propriile capcane. Pagina despre crearea unui magazin online arată concret ce intră în lucru și ce întrebări merită lămurite înainte să începi catalogul de produse.

Service-ul auto cu istoric pe fiecare mașină

Un service auto ajunge repede la nevoia unui portal de clienți online. Clientul intră cu numărul de înmatriculare și vede ce s-a schimbat la ultima revizie. Primește un mesaj când se apropie scadența ITP și aprobă din telefon un deviz suplimentar. Fiecare funcție pare mică luată separat, dar împreună înseamnă conturi, istoric, notificări și, aproape mereu, o legătură cu programul în care service-ul își ține deja fișele de lucru.

Aplicația folosită doar în interiorul firmei

Ultima categorie nu are nevoie de vizitatori din Google. Este o aplicație web pentru firmă, folosită de angajați sau parteneri: un calculator de preț pentru agenții de vânzări, un portal în care distribuitorii plasează comenzi, un sistem de rapoarte pentru echipele din teren. Aspectul public contează aproape deloc. Bugetul merge în logica de calcul și în integrări.

Costul unei aplicații web nu se ghicește din tabel. Tabelul îți arată doar unde să cauți. Ca ordin de mărime, un modul de programări adăugat peste un site existent pornește de regulă de la câteva mii de lei, iar un portal cu roluri și trei-patru integrări poate trece lejer de zece mii de euro.

Intervalul este larg pentru că totul depinde de scope, adică exact de ce scrie în analiză. Orice cifră precisă primită înaintea ei merită citită cu suspiciune.

Un prototip pe telefon, înainte de prima linie de cod

Prototipul este o machetă pe care poți da click, fără nimic funcțional în spate. Îl deschizi pe telefon, apeși pe butoane, treci prin pașii unei comenzi. Așa afli că formularul are prea multe câmpuri sau că omul din depozit nu are cum să bifeze o comandă cu mănușile de lucru pe mâini.

O modificare în prototip costă minute. După programare, aceeași modificare costă zile. Etapa merită luată în serios chiar când pare o întârziere. Aprobi prototipul în scris, ecran cu ecran.

Partea publică se desenează întâi pentru telefon. Acolo rezervă, comandă și verifică statusul majoritatea clienților, de multe ori cu o singură mână liberă. Panoul de administrare, folosit la birou, are alte reguli. Acolo contează tabelele mari și filtrele care găsesc rapid o comandă veche.

Programarea și integrările, cea mai scumpă parte din dezvoltarea web

După aprobarea prototipului începe partea pe care o vezi cel mai puțin. Programarea web pentru un IMM se face sănătos în etape scurte, de două-trei săptămâni, la capătul cărora primești ceva concret de testat. Testul are loc pe un server separat, numit de obicei mediu de test. Este o copie a aplicației unde poți greși fără ca greșeala să ajungă la clienții reali.

Tehnologia aleasă te interesează mai puțin ca proprietar, cu o excepție importantă: cât de ușor găsești peste cinci ani pe cineva care să continue lucrul. Un cadru de lucru răspândit (framework, în jargonul programatorilor), cu documentație bună și mulți programatori care îl cunosc, te protejează de dependența de o singură persoană. Argumentele concrete sunt în articolul despre când merită Laravel pentru o firmă din România.

Integrările, una câte una

Fiecare legătură cu alt sistem are prețul ei. Conectarea la un API, adică la interfața prin care două programe își trimit date, pare simplă pe hârtie. În practică, documentația are goluri. Contul de test se comportă altfel decât cel real, iar furnizorul schimbă câte ceva fără să anunțe.

Într-un proiect pentru piața românească, lista arată de obicei așa:

• plata cu cardul prin procesatori precum Netopia sau Stripe, inclusiv plățile refuzate și rambursările
• generarea AWB-ului la curier (Fan Courier, Sameday, Cargus) și actualizarea statusului livrării
• emiterea facturii prin programul de facturare pe care îl folosești deja, de exemplu SmartBill sau Oblio
• trimiterea contactelor și a comenzilor în CRM
• mesajele automate pe e-mail și SMS

Integrarea cu e-Factura cere o discuție separată. Sistemul RO e-Factura a devenit obligatoriu pentru facturile dintre firme din 2024, iar obligațiile s-au extins apoi și spre facturile către persoane fizice. Ce se aplică exact la tine confirmi cu contabilul.

Varianta cea mai simplă este, de regulă, ca site-ul să trimită comanda în programul de facturare, iar acesta să transmită factura mai departe în SPV. O conectare directă a aplicației la sistemele ANAF se justifică rar pentru un IMM.

Datele care se schimbă în timp real formează o categorie aparte. Pentru Cupa Liceelor Pitești, site-ul unei competiții de fotbal, am construit program, clasament, pagini de echipe și scoruri live. Un scor actualizat în timpul meciului pare un detaliu. Cere însă date corecte în fiecare moment, pentru oricine are pagina deschisă pe telefon.

Săptămâna de teste pe care toată lumea vrea să o scurteze

Spre final, presiunea crește. Lansarea a fost anunțată, procesatorul de plăți a aprobat contul, iar testarea pare singurul lucru care mai stă în cale. Tocmai pe ea nu ai voie să o comprimi.

Testarea serioasă se face cu oamenii care vor folosi aplicația, pe telefoanele lor, cu date reale. Recepționera introduce zece programări într-o dimineață aglomerată. Contabila verifică dacă facturile ies cu cota corectă de TVA. Cineva plasează o comandă cu un card refuzat, ca să vadă ce mesaj primește clientul.

Tot acum verifici viteza de încărcare a site-ului, pe o conexiune mobilă obișnuită și cu Wi-Fi-ul din birou oprit. PageSpeed Insights, instrumentul Google, oferă o imagine orientativă. Mai relevant rămâne ce simte cineva care deschide pagina din tramvai, cu semnal slab.

Ultima verificare privește datele personale: bannerul de cookie-uri, politica de confidențialitate și ce informații despre clienți păstrează aplicația, cât timp și cu cine le împarte. Echipa tehnică pregătește partea practică. Pentru interpretarea juridică, ultimul cuvânt îl are un consultant GDPR.

După lansare contează cine deține codul și cine răspunde la telefon

Ziua lansării pare un final. Pentru o aplicație, abia atunci începe viața reală. Primii clienți fac lucruri la care nu s-a gândit nimeni. Un browser primește o actualizare, iar curierul își modifică interfața de conectare.

Mentenanța unui site web construit la comandă acoperă câteva lucruri distincte: actualizările de securitate, copiile de siguranță, monitorizarea erorilor și micile corecturi. Funcțiile noi stau separat. Le estimezi și le plătești ca pe orice altă etapă. Un contract de mentenanță bun spune clar unde se termină una și unde începe cealaltă, plus în cât timp primești răspuns când ceva se strică într-o sâmbătă.

Patru rânduri din contract de citit de două ori

Întrebarea despre cine deține codul sursă pare teoretică până în ziua în care vrei să schimbi furnizorul. Contractul ar trebui să spună explicit că, după plata integrală, codul și drepturile de folosire îți aparțin. Al doilea rând privește accesul. Domeniul, hostingul și conturile la procesatorul de plăți sau la curier stau pe numele firmei tale, cu parolele la tine.

Al treilea rând se referă la preț. Un preț fix legat de analiză îți dă liniște, cu condiția ca orice modificare cerută pe parcurs să urmeze o procedură scrisă: o ceri, primești estimarea, aprobi sau renunți. Al patrulea acoperă garanția. Este perioada în care furnizorul repară fără cost suplimentar erorile descoperite după lansare.

Mai rămâne un criteriu, greu de pus în contract. Un proiect de dezvoltare web durează luni, iar mentenanța ani, așa că merită să vorbești direct cu oamenii care scriu codul, fără trei niveluri de intermediari între tine și o problemă urgentă. La noi vorbești pe WhatsApp și la telefon (0764 678 678) chiar cu cei care construiesc site-ul. Un furnizor care îți răspunde greu la ofertă va răspunde la fel de greu și în ziua în care nu merge plata.

Înainte să ceri următoarea ofertă

Scrie pe o singură pagină cum decurge azi, pas cu pas, procesul pe care vrei să-l muți online. Notează programele pe care le folosești deja și oamenii care ating fiecare pas. Cu pagina asta în mână, orice ofertă devine comparabilă, inclusiv cea pentru dezvoltare web personalizată de la BoringWeb, care pornește tot de la o discuție de o oră. O ofertă care nu îți pune nicio întrebare despre acea pagină îți spune deja destul.