Întrebarea reală din spatele lui „avem noi drepturile asupra codului?” e de obicei alta: ce se întâmplă dacă colaborarea se oprește vreodată? Punctul nostru de plecare e simplu: trebuie să poți merge mai departe cu software-ul, cu noi sau fără noi. Asta ține de codul-sursă, de predare și de cine face securitatea și patch-urile cât timp suntem încă aici.
Ce e al tău
Tot ce construim specific pentru proiectul tău e al tău. Logica aplicației, cuplajele, temele, configurarea și datele dezvoltate special pentru firma ta trec la tine.
Aducem în proiecte și cod Baldwin existent: starter kit-ul nostru și câteva module reutilizabile pentru lucruri pe care altfel le-am construi de fiecare dată de la zero. Alea rămân ale noastre, dar primești un drept de folosință perpetuu. Le poți folosi și adapta în continuare, iar mai târziu alt developer poate lucra liniștit cu ele.
Nu există cod ofuscat, nicio cheie de licență care expiră și nimic care se oprește când se oprește colaborarea.
Tehnologie standard dedesubt
Componentele noastre nu sunt un framework închis pe care doar noi îl înțelegem. Dedesubt folosim tehnologie consacrată, cum ar fi Magento, Hyvä, WordPress, PHP, Python și Symfony.
Reutilizăm cod pentru că e mai rapid, mai sigur și mai ieftin decât să construim de fiecare dată același lucru — nu ca să te facem dependent de noi.
Unde stă codul
Cât timp lucrăm împreună, ținem repository-ul în mediul nostru. Tu primești acces la cod, iar noi păstrăm acces atât timp cât răspundem de dezvoltare.
E mai ales o chestiune practică: trebuie să putem lucra la proiect cât timp merge colaborarea și nu vrem să fim scoși brusc dintr-un mediu în timp ce încă se livrează sau se facturează muncă.
Dacă se oprește colaborarea, ține de asta și o predare clară. Imediat ce proiectul e închis administrativ, transferăm tot repository-ul, iar de-atunci îl administrezi tu sau împreună cu următorul tău partener de dezvoltare.
Poate prelua alt developer?
Da. Un partener nou primește acces la tot codul și la documentația relevantă ca să înțeleagă cum e făcut sistemul.
Dacă e nevoie, ne așezăm și cu echipa nouă pentru o predare. Timpul ăla îl facturăm ca orice altă muncă, dar să îngreunăm o predare nu facem.
Software-ul pe care doar constructorul inițial îl poate întreține nu e, pentru noi, software bine construit.
Prețuri spune cât costă mentenanța, iar Securitate intră mai adânc în NIS2 și politica de patch-uri.
Software-ul nu se oprește la lansare
Site-urile, magazinele online și platformele vin cu un SLA. Nu doar ca să reacționăm când se strică ceva, ci mai ales ca tehnologia pe care e construit software-ul tău să țină pasul.
Pentru site-urile WordPress și magazinele online Magento putem estima destul de bine câtă mentenanță cere fiecare an. De-asta acolo lucrăm cu pachete fixe:
- Site-uri WordPress:de la 24 de ore pe an.
- Magazine online Magento:de la 40 de ore pe an.
- Platforme:dimensionat după tehnologia folosită și amploarea platformei.
La o platformă e mai greu de prins într-o singură cifră fixă. PHP, Python, Symfony, MySQL, librăriile, API-urile și alte componente evoluează fiecare în ritmul lor. De-asta ne uităm per platformă ce tehnologie cere mentenanță și câtă capacitate e realistă.
La tiny products ne uităm per produs. Sunt deliberat mici și bine delimitate, deci nu au automat nevoie de un SLA. Dacă un astfel de tool devine critic pentru firmă sau cere mentenanță structurală, facem o înțelegere separată.
Actualizări și securitate
Un SLA înseamnă pentru noi mai mult decât să reacționăm când se strică ceva. Prevedem capacitate pentru actualizări, upgrade-uri, patch-uri de securitate și mentenanță tehnică, ca software-ul să nu îmbătrânească pe tăcute în timp ce pe dinafară pare că merge perfect.
În ultimii ani asta a devenit tot mai important. Software-ul se sprijină pe tot mai multe librării, API-uri și componente externe, iar odată cu dezvoltarea rapidă din jurul AI cresc puternic și numărul de dependențe, și ritmul actualizărilor de securitate.
De-asta problemele critice de securitate nu așteaptă sprintul următor planificat. Actualizările, patch-urile sau vulnerabilitățile care cer atenție imediată au prioritate.
Când se strică ceva
Pentru clienții cu SLA tratăm problemele critice cu prioritate. Un magazin online care nu e accesibil, un checkout care pică sau o cuplare crucială care cade nu așteaptă până se face din nou loc în planificarea obișnuită de sprint.
În timpul programului de lucru încercăm să răspundem la sesizările critice în două până la patru ore.
Un răspuns înseamnă că cineva chiar s-a uitat la problemă și îți poate spune ce se întâmplă și care e pasul următor. Nu doar că s-a creat un tichet undeva.
Întrebări pe care le primim des
Avem noi drepturile asupra codului? Pe tot ce se dezvoltă specific pentru proiectul tău, da. Starter kit-ul nostru și modulele reutilizabile rămân ale Baldwin, dar primești un drept de folosință perpetuu și alt developer poate lucra mai departe cu ele.
Pot lucra mai târziu alți developeri la codul vostru? Da. Lucrăm cu tehnologie standard, ai acces la cod, iar la ieșire transferăm repository-ul și documentația relevantă. Dacă e nevoie, însoțim și predarea către echipa nouă.
Unde stă codul nostru în timpul colaborării? Repository-ul e administrat de Baldwin și tu primești acces la el. Așa păstrează ambele părți acces cât timp lucrăm împreună la proiect. La ieșire, repository-ul se transferă integral după închiderea administrativă.
Cum gestionați actualizările, upgrade-urile și patch-urile de securitate? Pentru site-uri, magazine online și platforme lucrăm cu un SLA în care e prevăzută capacitate pentru mentenanță tehnică, actualizări și securitate. Pentru WordPress și Magento avem pachete anuale fixe; la platforme dimensionăm capacitatea după tehnologie și complexitate.
Ce se întâmplă la o problemă critică de securitate? Are prioritate față de planificarea obișnuită. Nu lăsăm patch-urile critice și problemele de securitate să aștepte sprintul următor.