Sebelum membuat aplikasi mobile untuk bisnis, jawab satu pertanyaan dulu: berapa kali dalam sebulan pelanggan atau staf Anda akan membukanya? Bila jawabannya kurang dari sekali, website yang cepat hampir selalu lebih masuk akal. Di bawah ini ada alur keputusan, biaya tahunan yang jarang dibicarakan di awal, aturan rilis Google Play yang berlaku sekarang, dan brief satu halaman yang bisa langsung Anda kirim ke calon pengembang.

Aplikasi, website, atau cukup WhatsApp?

Aplikasi harus diunduh, dipasang, lalu diberi izin. Tiga langkah itu hanya mau dilalui orang yang yakin akan kembali. Toko bangunan yang pelanggannya belanja tiga kali setahun tidak akan mendapat banyak unduhan, sebagus apa pun aplikasinya. Laundry kiloan dengan pelanggan langganan mingguan berbeda ceritanya: ada alasan untuk membuka aplikasi tiap Senin.

Ukuran kedua adalah fitur perangkat. Absensi staf lapangan dengan foto dan lokasi, pemindai kode batang di gudang, atau notifikasi status pesanan yang harus sampai walau browser tertutup memang lebih andal sebagai aplikasi. Katalog produk, formulir pemesanan, dan halaman profil usaha tidak butuh semua itu.

Ada jalan tengah bernama Progressive Web App (PWA), yaitu website yang bisa dipasang ke layar utama dan terbuka di jendela sendiri seperti aplikasi (web.dev). Untuk banyak usaha, PWA adalah langkah pertama yang lebih murah sebelum memutuskan masuk toko aplikasi.

Lalu kapan WhatsApp saja sudah cukup? Selama pesanan masih bisa dibalas satu orang admin tanpa antre, dan pelanggan tidak perlu melihat riwayat atau status sendiri. Begitu admin mulai menyalin pesanan dari chat ke buku atau spreadsheet setiap malam, itu tanda proses sudah butuh sistem. Sistem itu pun belum tentu aplikasi: formulir pesanan di website yang tersambung ke kasir sering menyelesaikan masalah yang sama.

Alasan yang paling lemah adalah "supaya terlihat profesional". Ambil contoh aplikasi yang diunduh 200 kali lalu tidak dibuka lagi justru memberi beban: tetap harus diperbarui, akun toko tetap harus dibayar, dan ulasan buruk tetap terlihat publik. Kalau tujuannya citra, website yang cepat dan rapi biasanya memberi hasil yang sama dengan biaya jauh lebih kecil.

Alur keputusan membuat aplikasi mobile untuk bisnis: frekuensi pemakaian, kebutuhan fitur perangkat, lalu pilihan website, PWA, atau aplikasi
Alur keputusan sebelum membuat aplikasi mobile. Disusun oleh Tim Zonaku.

Tulis satu tujuan yang bisa diukur sebelum menyusun fitur

"Supaya bisnis lebih digital" bukan tujuan. Tujuan yang bisa dipakai bentuknya seperti ini: mengurangi pesan WhatsApp yang menanyakan status pesanan, membuat pelanggan lama memesan ulang tanpa ditelepon, atau memindahkan rekap absensi dari kertas ke sistem sebelum tanggal tutup gaji.

Dari situ, versi pertama cukup berisi tiga sampai lima alur. Contoh untuk laundry: pelanggan login dengan nomor ponsel, melihat status cucian, menerima notifikasi saat siap diambil, dan melihat riwayat nota. Fitur poin, ulasan, dan promo bisa menunggu sampai ada data siapa yang benar-benar memakai aplikasinya. Semakin pendek daftar fitur awal, semakin cepat Anda tahu apakah aplikasi itu dipakai.

Android dulu, atau langsung Android dan iOS?

Per Oktober 2026, Android dipakai di 78,68% perangkat seluler di Indonesia dan iOS di 21,28% (Statcounter). Untuk aplikasi staf internal atau pelanggan pasar umum, Android saja sering sudah cukup untuk versi pertama.

Pengecualiannya jelas. Bila pelanggan Anda klinik estetika di kota besar, perusahaan dengan ponsel dinas, atau segmen yang cenderung memakai iPhone, rilis hanya di Android berarti mengabaikan pelanggan dengan nilai belanja paling tinggi. Kerangka lintas platform memungkinkan satu basis kode untuk keduanya, tetapi pengujian, akun toko, dan proses review tetap dua kali.

Biaya yang datang setiap tahun setelah aplikasi terbit

Anggaran pembuatan biasanya dibahas panjang. Biaya sesudahnya sering baru muncul ketika tagihan datang.

Pos Besaran Sifat
Akun Google Play Console USD 25 (Google) Sekali bayar
Apple Developer Program USD 99 per tahun keanggotaan (Apple) Tahunan
Penyesuaian target API Android Waktu pengembang, tergantung perubahan Tahunan
Server, domain, penyimpanan cloud Tergantung jumlah pengguna Bulanan
Perbaikan bug dan pembaruan sistem operasi Kontrak pemeliharaan Berkelanjutan

Baris ketiga paling sering terlupa. Google menaikkan batas target API setiap tahun: mulai 31 Agustus 2026, aplikasi baru dan pembaruan wajib menargetkan Android 16 (API level 36). Aplikasi lama yang belum menargetkan minimal API level 35 tidak lagi tampil bagi pengguna baru di versi Android yang lebih tinggi (Android Developers). Artinya, aplikasi yang tidak disentuh dua tahun pelan-pelan menghilang dari Play Store.

Rilis pertama di Play Store butuh minimal dua minggu

Akun Play Console pribadi yang dibuat setelah 13 November 2023 wajib menjalankan uji tertutup dengan minimal 12 penguji yang ikut tanpa putus selama 14 hari sebelum bisa mengajukan akses produksi (Bantuan Play Console). Penguji yang keluar sebelum hari ke-14 tidak dihitung.

Dalam praktik, siapkan 15 sampai 20 orang, misalnya staf dan pelanggan setia, karena selalu ada yang lupa memasang. Lebih baik lagi, daftarkan akun atas nama perusahaan sejak awal. Aturan 12 penguji tertulis untuk akun pribadi, dan akun perusahaan juga menyelesaikan masalah kepemilikan yang dibahas di bagian berikutnya. Jangan menjadwalkan peluncuran dan promosi di minggu yang sama dengan selesainya pengembangan.

Hal yang biasanya terlupa, dari sisi pembuat sistem

Kami membangun sistem kasir, HR, sekolah, dan website. Masalah yang paling merepotkan jarang ada di kode, melainkan di urusan administrasi yang dilewati di minggu pertama:

  • Akun Google Play dan Apple terdaftar atas nama pribadi pengembang, bukan perusahaan Anda. Saat kerja sama berakhir, memindahkan aplikasi menjadi urusan panjang.
  • Kode sumber dan kunci penandatanganan aplikasi tidak diserahkan. Tanpa kunci itu, pembaruan berikutnya bisa tertahan.
  • Panel admin tidak masuk lingkup. Aplikasi pelanggan jadi, tetapi staf tetap mengubah harga lewat pengembang.
  • Tidak ada yang ditugaskan membalas ulasan di toko aplikasi, sehingga keluhan gagal login menumpuk tanpa jawaban di halaman yang dilihat calon pengguna.
  • Data pelanggan dikumpulkan tanpa kebijakan privasi. Nomor ponsel dan alamat adalah data pribadi yang diatur UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi.

Brief satu halaman untuk calon pengembang

Kirim isi berikut sebelum meminta penawaran. Pengembang yang serius akan bertanya balik soal butir yang masih kosong. Itu tanda bagus.

  1. Tujuan utama dalam satu kalimat, beserta angka pembandingnya (contoh: 40 pesan "sudah selesai belum?" per hari).
  2. Siapa penggunanya: pelanggan, staf, atau keduanya, dan kira-kira berapa orang di tahun pertama.
  3. Tiga sampai lima alur wajib versi pertama.
  4. Platform: Android saja, iOS, atau PWA dulu.
  5. Sistem yang harus tersambung: kasir, pembukuan, pembayaran, atau spreadsheet yang dipakai sekarang.
  6. Siapa yang mengelola konten dan harga setelah rilis.
  7. Kepemilikan: akun toko, kode sumber, dan kunci atas nama perusahaan.
  8. Pemeliharaan: berapa lama masa garansi bug, dan siapa yang menangani pembaruan target API tiap tahun.

Untuk urutan kerja setelah brief disepakati, lihat tahapan pengembangan aplikasi dari ide hingga siap digunakan. Bila kebutuhan masih bisa berubah di tengah jalan, pembahasan Waterfall vs Agile membantu memilih cara kontraknya.

Cara Zonaku membantu

Tim Zonaku mengerjakan aplikasi kustom yang disusun mengikuti proses bisnis Anda, termasuk integrasi dengan sistem kasir, CRM, atau ERP yang sudah berjalan, plus dukungan setelah rilis.

Langkah berikutnya: isi delapan butir brief di atas, walau sebagian masih "belum tahu", lalu kirimkan lewat halaman kontak. Konsultasi awal gratis, dan dari situ kita bisa menilai apakah yang Anda butuhkan memang aplikasi atau cukup website.