Mengambil alih aplikasi? Cari dulu akar masalahnya.
Setiap perbaikan seolah memunculkan masalah baru di tempat lain. Ini yang kami periksa di dua minggu pertama saat mengambil alih aplikasi dari vendor lain.
Di akhir 2025, aplikasi travel bernama Neebu datang ke kami dengan cerita yang tidak asing. Aplikasinya sampai di app store jauh lebih lambat dari rencana. Setiap perbaikan dari tim sebelumnya seolah memunculkan masalah baru di tempat lain. Klien tidak ingin aplikasinya dibuat ulang. Mereka ingin ada yang bertanggung jawab atas semuanya.
Kami sudah beberapa kali menangani serah terima seperti ini. Dua minggu pertamanya selalu mengikuti rencana yang sama.
1. Kumpulkan semua kunci, bukan hanya kodenya.
Kode hanyalah sebagian kecil. Sebelum menyentuh satu baris pun, kami mengumpulkan akses ke akun app store, server, domain, kunci push notification, signing key Android dan iOS, serta setiap layanan pihak ketiga yang dipakai aplikasi. Kalau satu saja tertinggal, perbaikan yang sudah jadi tidak bisa dirilis. Itu pun baru ketahuan di saat paling genting.
Langkah ini membosankan. Tetapi di sinilah kebanyakan serah terima diam-diam gagal.
2. Build sekali, di komputer yang bersih.
Berikutnya, kami mem-build aplikasinya dari awal di komputer yang belum pernah dipakai untuk aplikasi itu. Kalau gagal, setiap perbaikan sesudahnya hanyalah tebakan yang bergantung pada laptop seseorang.
Alat yang dipakai untuk membuatnya biasanya sudah tertinggal beberapa tahun. Kami memperbaruinya di tahap ini, tanpa gaduh, sebelum ada perubahan yang terlihat. Dengan begitu, klien tidak perlu bertanya-tanya apakah sebuah bug muncul karena perbaikan atau karena pembaruan.
3. Cari bug yang penyebabnya sama.
Klien datang membawa daftar. Daftar Neebu panjang dan bernomor. Alih-alih mulai dari nomor satu, kami membaca semuanya dulu.
Kalau bug terus muncul lagi di tempat lain, penyebabnya hampir selalu salah satu dari tiga hal ini:
- Informasi yang sama disimpan di dua tempat, dan hanya satu yang diperbarui.
- Aplikasi lupa sesuatu yang seharusnya ia ingat.
- Aplikasi dan server tidak sepakat soal satu aturan.
Sepuluh bug bisa jadi hanya satu masalah yang menyamar sepuluh kali.
4. Perbaiki di tempat rusaknya.
Di Neebu, notifikasi yang membuka halaman yang salah ternyata sama sekali bukan bug aplikasi. Server mengirim satu field dengan nama yang salah eja. Begitu namanya dibetulkan, semua notifikasi beres sekaligus. Menambal aplikasinya hanya akan membereskan satu.
Begitulah daftar bug memendek, bukan sekadar berpindah tempat.
5. Rilis kecil, rilis sering.
Rilis besar yang datang terlambat membuat kepercayaan hilang. Jadi kami mengirim update kecil ke kedua store, dengan ritme yang bisa direncanakan klien. Daftar milik klien sendiri menjadi catatan rilisnya. Teratur lebih penting daripada cepat.
Serah terima dengan cara ini membuat produk terasa berbeda bagi pemiliknya. Neebu kini rilis sesuai jadwal, dan masalah yang terbuka makin sedikit, bukan berpindah tempat. Yang bermula sebagai pengambilalihan kini menjadi retainer tetap.
Kalau Anda sedang memegang aplikasi yang tidak lagi Anda percayai, ceritakan pada kami. Dua minggu pertamanya selalu sama, siapa pun yang membuatnya.
