Developerul aplicației tale a dispărut? Ce faci în primele 7 zile

Aplicația funcționează, clienții o folosesc, dar cel care a construit-o nu mai răspunde la mesaje. Poate a schimbat domeniul, poate firma lui s-a închis, poate pur și simplu a dispărut. Între timp, Apple cere o actualizare, un client raportează o eroare sau serverul trebuie plătit și nu știi unde.

Situația e mai des întâlnită decât pare, iar vestea bună este că de cele mai multe ori se poate rezolva. Important e să afli repede ce controlezi și ce nu, înainte ca o problemă mică să devină o întrerupere.

Zilele 1 și 2: află ce controlezi de fapt

Înainte să cauți un developer nou, fă un inventar. Pentru fiecare element de mai jos, notează unde se află, pe numele cui este și dacă ai acces la el.

• Codul sursă: există un repository (GitHub, GitLab, Bitbucket)? Ești proprietar sau doar invitat? Dacă singura copie e pe laptopul fostului developer, asta e prioritatea numărul unu.
• Contul Apple Developer: aplicația e publicată din contul firmei tale sau din contul developerului? Cine are rolul de Account Holder?
• Google Play Console: aceeași întrebare. Contul de dezvoltator e al tău sau al lui?
• Serverul și baza de date: unde rulează backend-ul (AWS, Google Cloud, Firebase, un VPS)? Cine plătește factura? Există copii de siguranță și unde sunt?
• Domeniul și DNS-ul: pe numele cui e înregistrat domeniul și când expiră? Dacă expiră, se opresc și site-ul, și API-ul, și emailurile.
• Serviciile plătite: procesatorul de plăți, serviciul de email, notificările, hărțile, API-urile de AI. Fiecare are un cont, o cheie de acces și un card pe care se face plata.

La final ar trebui să ai o listă simplă cu trei coloane: ce e al tău, ce e al developerului și ce nu știi. A treia coloană îți spune unde începi.

Zilele 2 și 3: recuperează ce lipsește

Dacă aplicația e publicată din contul developerului, nu trebuie să o reconstruiești de la zero. Atât Apple, cât și Google permit mutarea unei aplicații într-un alt cont de dezvoltator, păstrând utilizatorii și recenziile. Apple descrie procesul în ghidul despre transferul aplicațiilor, iar Google în documentația Play Console. În ambele cazuri, transferul trebuie inițiat din contul în care se află aplicația acum, deci ai nevoie de colaborarea fostului developer. Transferul mută doar aplicația din magazin, nu și codul: pe acesta trebuie să ți-l predea separat. Dacă aplicația folosește notificări push, Sign in with Apple, abonamente sau plăți în aplicație, transferul are pași tehnici în plus, pe care e bine să-i parcurgi cu un developer.

Dacă acesta nu răspunde deloc, scoate contractul. Uită-te ce spune despre proprietatea asupra codului, predarea conturilor și ce se întâmplă la încetarea colaborării. Dacă nu există contract sau formulările sunt neclare, merită o discuție cu un avocat înainte să faci alți pași. Cu cât aplicația e mai importantă pentru afacere, cu atât mai repede.

Între timp, asigură-te că nu se oprește nimic din motive banale: plătește domeniul și serverul dacă poți, schimbă parolele conturilor la care ai acces și verifică ce date de facturare sunt folosite.

Zilele 3, 4 și 5: evaluarea tehnică

Când ai codul și accesul la servere, un developer nou poate spune în ce stare e aplicația. O evaluare serioasă răspunde la câteva întrebări concrete:

1. Se compilează? Poate fi construită aplicația pornind de la cod, pe un calculator nou, fără ajutorul autorului?
2. Cât de vechi sunt dependențele? Bibliotecile neactualizate de ani de zile pot împiedica o actualizare în magazin sau pot ascunde probleme de securitate.
3. Respectă cerințele actuale ale magazinelor? Magazinele ridică periodic cerințele minime. De exemplu, din 31 august 2026, Google Play acceptă aplicații noi și actualizări doar dacă țintesc Android 16, iar aplicațiile vechi rămase în urmă nu mai apar pentru utilizatorii noi cu telefoane recente. O aplicație neactualizată de mult poate avea nevoie de câteva zile de lucru înainte să poți publica o simplă corectură.
4. Unde sunt cheile și parolele? Chei de acces scrise direct în cod sau trimise pe chat trebuie schimbate.
5. Există documentație sau teste? Nu sunt obligatorii, dar lipsa lor crește timpul pentru orice modificare.

Rezultatul ar trebui să fie un raport scris, nu o impresie. Ce funcționează, ce e urgent, ce poate aștepta și cât ar costa fiecare parte, aproximativ.

Repari sau rescrii?

Prima tentație a multor developeri când văd codul altcuiva e să propună rescrierea. Uneori e varianta corectă, dar de cele mai multe ori nu. O rescriere costă mult, durează și reintroduce probleme pe care versiunea veche le rezolvase deja.

Semne că merită reparată

• Aplicația se compilează și funcțiile principale merg.
• Tehnologia folosită e încă întreținută (de exemplu Flutter, React Native, Swift sau Kotlin la versiuni rezonabile).
• Problemele sunt localizate: câteva ecrane, o integrare, un serviciu.

Semne că rescrierea e luată în calcul pe bune

• Codul nu mai poate fi compilat și aducerea lui la zi costă aproape cât o versiune nouă.
• Tehnologia nu mai e întreținută și nu mai poate fi publicată în magazine.
• Produsul s-a schimbat atât de mult încât jumătate din aplicație nu mai e folosită.

Chiar și atunci, o rescriere se poate face pe etape: păstrezi backend-ul și datele, refaci aplicația mobilă, sau invers. Rareori e nevoie să arunci totul deodată.

Zilele 6 și 7: stabilește cine are grijă de aplicație de acum înainte

După evaluare, ai nevoie de un plan pentru lunile următoare: cine aplică actualizările, cine răspunde când ceva se strică, cât de repede și cum se estimează funcțiile noi. Am scris mai pe larg despre asta în articolul despre mentenanța unei aplicații după lansare.

Pentru aplicațiile preluate, primele săptămâni sunt de obicei cele mai aglomerate: actualizări de dependențe, cerințe noi de la magazine, chei de acces schimbate, documentația care lipsea. Un abonament lunar acoperă bine perioada asta, pentru că poți schimba prioritățile de la o săptămână la alta fără să negociezi o ofertă nouă pentru fiecare problemă.

Cum eviți situația data viitoare

Indiferent cu cine lucrezi, inclusiv cu mine, câteva reguli simple te protejează:

• Contul Apple Developer, contul Google Play, domeniul și contul de cloud sunt pe numele firmei tale. Developerul primește acces, nu proprietatea.
• Codul stă într-un repository al tău, actualizat continuu, nu doar la final.
• Contractul spune clar că, după plată, codul și conturile îți aparțin.
• Există un document scurt cu toate serviciile folosite, unde rulează și cine le plătește.
• Cel puțin încă o persoană din firma ta are acces de administrator la tot ce e important.

La proiectele pe care le dezvolt la comandă, codul sursă aparține clientului după plată, iar detaliile sunt trecute în propunere, înainte de start.

Ai o aplicație rămasă fără developer?

Dacă te afli acum în situația asta, scrie-mi ce ai: în ce tehnologie e făcută aplicația, la ce conturi ai acces și ce te îngrijorează cel mai mult. Îți spun ce pași ar urma și dacă un abonament de mentenanță și dezvoltare e potrivit pentru tine.