Vendor Aplikasi Lama Menghilang? Ini Cara Menyelamatkan Aplikasi Anda

Ceritanya hampir selalu sama. Aplikasi dibangun dua atau tiga tahun lalu, jalan dengan baik, lalu suatu hari ada bug atau kebijakan Play Store berubah. Anda menghubungi vendor lama. Nomornya tidak aktif. Emailnya tidak dibalas. Atau dibalas, tapi dengan harga yang tidak masuk akal karena mereka tahu Anda tidak punya pilihan.

Ini salah satu situasi paling sering yang kami bantu tangani. Kabar baiknya: hampir selalu bisa diselamatkan. Kabar kurang baiknya: seberapa mudahnya tergantung apa yang Anda pegang sekarang.

Langkah 1: Inventarisasi apa yang Anda punya

Sebelum menghubungi siapa pun, kumpulkan ini. Centang yang ada:

• Kode sumber aplikasi (biasanya folder proyek atau akses ke GitHub/GitLab/Bitbucket)
• Kode sumber backend/server (bagian yang menyimpan data, sering terpisah dari aplikasinya)
• Akses Google Play Console dan Apple Developer / App Store Connect atas nama perusahaan Anda
• Akses server/hosting (AWS, Google Cloud, Niagahoster, dll.) dan domain
• Akses database
• File signing key Android (.jks / keystore) beserta password-nya
• Akun layanan pihak ketiga: Firebase, payment gateway, SMS OTP, peta
• Dokumentasi apa pun, sekecil apa pun

Kalau Anda mencentang kode sumber + akses store + akses server, situasinya baik. Kalau hanya sebagian, masih bisa. Kalau tidak ada sama sekali, tetap ada jalan, tapi lebih panjang.

Langkah 2: Amankan yang paling kritis lebih dulu

Urutan prioritas:

1. Akses store. Kalau akun Play Console/App Store atas nama vendor, minta transfer kepemilikan sekarang, selagi masih bisa dihubungi. Tanpa ini, Anda tidak bisa merilis update apa pun, dan aplikasi lama bisa dihapus dari store kapan saja.
2. Signing key Android. Tanpa file ini, update aplikasi Android tidak bisa dipasang di atas versi lama; pengguna harus uninstall dan install ulang. Untuk aplikasi dengan banyak pengguna, ini bencana. (Kalau memakai Play App Signing, Google yang menyimpan kuncinya dan risikonya lebih kecil.)
3. Server dan database. Pastikan tagihan hosting dibayar atas nama Anda dan Anda punya akses admin. Vendor yang menghilang kadang berarti server yang berhenti dibayar.
4. Kode sumber. Kalau belum punya, minta. Secara hukum, kalau kontrak menyebut kode adalah milik Anda (dan sebaiknya begitu), Anda berhak memintanya.

Langkah 3: Nilai kondisi kodenya

Setelah kode di tangan, minta pengembang baru melakukan audit singkat (biasanya 2–5 hari kerja) sebelum menyetujui apa pun. Yang perlu dijawab:

• Apakah kodenya bisa di-build (dijadikan aplikasi) di komputer selain milik vendor lama? Ini tes pertama dan sering gagal karena ada file konfigurasi yang tidak disertakan.
• Teknologi apa yang dipakai, dan versi berapa? Aplikasi Flutter versi 2 tahun lalu masih bisa dilanjutkan. Aplikasi dengan framework yang sudah tidak dikembangkan lagi, lebih sulit.
• Seberapa rapi kodenya? Bukan soal selera, tapi soal: apakah orang baru bisa memahaminya dalam hitungan hari, bukan minggu?
• Apakah ada bagian yang bergantung pada layanan milik vendor (server mereka, akun mereka)? Ini harus dipindahkan.

Hasil audit menentukan jalan ke depan.

Langkah 4: Pilih jalannya

Ada tiga kemungkinan hasil audit, dan masing-masing punya jalan yang berbeda:

Kondisi baik: lanjutkan. Kode bisa di-build, teknologinya masih hidup, strukturnya bisa dipahami. Pengembang baru mengambil alih, memperbarui library yang usang, dan melanjutkan. Ini hasil yang paling umum, dan biayanya jauh lebih murah daripada bikin ulang.

Kondisi sedang: perbaiki bertahap. Kode jalan tapi berantakan atau memakai versi yang sangat tua. Strategi: rilis satu update kecil dulu untuk memastikan jalur rilisnya berfungsi, lalu perbaiki bagian per bagian sambil tetap menjalankan aplikasi.

Kondisi buruk: bangun ulang. Kode tidak bisa di-build, teknologi mati, atau tidak ada kode sama sekali. Bangun ulang terdengar mahal, tapi ada sisi positifnya: Anda sudah tahu persis fitur apa yang dipakai dan mana yang tidak. Versi baru biasanya lebih ramping dan lebih cepat selesai daripada proyek pertama.

Cara mencegah ini terjadi lagi

Saat memilih vendor baru, pastikan secara tertulis:

1. Kode sumber milik Anda, disimpan di repository atas nama perusahaan Anda, dan vendor hanya diberi akses.
2. Semua akun (store, server, layanan pihak ketiga) atas nama perusahaan Anda.
3. Ada dokumentasi cara build dan deploy yang diserahkan di akhir proyek.
4. Ada kesepakatan serah terima kalau kerja sama berakhir, apa pun alasannya.

Vendor yang baik tidak akan keberatan dengan semua ini. Justru vendor yang menolak adalah tanda bahaya.

---

Kalau Anda sedang di posisi ini, hubungi kami dengan daftar centang di Langkah 1. Dari situ kami bisa memperkirakan seberapa rumit situasinya, biasanya dalam satu percakapan.