“Berapa biaya bikin aplikasi?” adalah pertanyaan yang tidak bisa dijawab dengan satu angka, dan bukan karena vendor sengaja menghindar. Penyebabnya lebih mendasar: yang menentukan harga bukan jumlah halaman, melainkan jumlah keputusan yang harus dibuat.
Dua aplikasi dengan jumlah layar yang sama bisa berbeda biaya berkali lipat, tergantung apakah alur pembayarannya sudah baku, apakah datanya harus dipindahkan dari sistem lama, dan berapa banyak pengecualian yang selama ini ditangani manusia dan sekarang harus ditulis sebagai aturan.
Enam komponen yang membentuk harga
| Komponen | Yang dikerjakan | Kenapa sering diremehkan |
|---|---|---|
| Analisis dan pemetaan alur | Menerjemahkan proses bisnis jadi spesifikasi | Terlihat seperti rapat, padahal menentukan seluruh biaya berikutnya |
| Desain antarmuka | Alur layar, tata letak, dan komponen | Revisi desain jauh lebih murah daripada revisi kode |
| Pengembangan | Menulis fitur di sisi tampilan dan server | Bagian yang paling terlihat, tapi jarang paling mahal |
| Integrasi | Payment gateway, kurir, akuntansi, sistem lama | Sering ditemukan di tengah jalan dan mengubah anggaran |
| Pengujian dan perbaikan | Menemukan dan menutup celah sebelum tayang | Dipangkas ketika mengejar tenggat, lalu dibayar dua kali |
| Migrasi data dan pelatihan | Memindahkan data lama dan menyiapkan tim | Paling sering dilupakan, padahal menentukan adopsi |
Satu kalimat yang menghemat banyak uang: Minta penawaran dipecah per komponen di atas. Vendor yang bisa memecahnya biasanya sudah memikirkan pekerjaannya; yang tidak bisa, sedang menebak — dan tebakan itu akan menjadi tagihan tambahan Anda.
Kenapa penawaran bisa berbeda tiga sampai sepuluh kali lipat
Perbedaan besar antar penawaran hampir selalu berasal dari empat sumber, dan hampir tidak pernah dari “yang satu mahal, yang satu murah”.
- Cakupan yang berbeda diam-diam. Yang satu memasukkan pengujian, migrasi, dan pelatihan; yang lain hanya menghitung pengembangan.
- Tingkat kustomisasi. Membangun dari nol berbeda jauh dari menyesuaikan sistem yang sudah ada.
- Siapa yang mengerjakan. Tim senior lebih mahal per jam, tetapi sering lebih murah per fitur karena lebih sedikit pengerjaan ulang.
- Model kepemilikan. Harga akan berbeda jika Anda meminta kepemilikan penuh atas kode dibandingkan hanya hak pakai.
Tiga jalur, tiga struktur biaya
Sebelum meminta penawaran, tentukan dulu jalur mana yang sebenarnya Anda butuhkan. Banyak anggaran habis karena perusahaan memilih jalur paling mahal untuk kebutuhan yang sebenarnya biasa saja.
| Jalur | Kapan masuk akal | Struktur biaya |
|---|---|---|
| Beli sistem jadi | Kebutuhan Anda standar dan waktunya mendesak | Sekali bayar, lalu server dan pemeliharaan |
| Semi-custom | Sistem jadi hampir cocok, perlu penyesuaian | Harga sistem plus biaya penyesuaian |
| Custom penuh | Proses Anda unik dan menjadi keunggulan bersaing | Paling mahal di depan, paling fleksibel jangka panjang |
Sebagai gambaran nyata, sistem siap pakai yang sudah teruji berada di rentang yang sangat lebar tergantung cakupannya. Di katalog MDH sendiri, plugin dan sistem ringan berada di kisaran ratusan ribu hingga satu juta rupiah, platform CRM omnichannel siap produksi di kisaran tujuh setengah juta, aplikasi mobile bermerek sendiri di kisaran sepuluh juta, dan sistem POS lengkap dengan modul HRM di kisaran lima puluh juta karena cakupannya jauh lebih luas.
Angka-angka itu berguna sebagai jangkar. Jika penawaran custom yang Anda terima jauh di atas harga sistem jadi yang sudah mencakup kebutuhan Anda, tanyakan apa tepatnya yang tidak bisa dipenuhi sistem jadi itu.
Biaya yang muncul setelah aplikasi jadi
Ini bagian yang paling sering hilang dari anggaran, dan yang paling sering membuat sistem terbengkalai setahun kemudian.
Aturan sederhana: Anggarkan pemeliharaan tahunan sebagai persentase tetap dari nilai proyek, sepakati cakupannya secara rinci, dan tetapkan waktu tanggap ketika terjadi gangguan. Sistem tanpa anggaran pemeliharaan adalah sistem yang sedang menunggu ditinggalkan.
Cara memangkas biaya tanpa memangkas hasil
- Kurangi fitur, bukan kualitas. Rilis lebih sedikit fitur yang benar-benar dipakai lebih baik daripada banyak fitur setengah jadi.
- Rapikan proses sebelum membangun. Setiap pengecualian yang Anda hapus di atas kertas adalah biaya yang tidak jadi keluar.
- Pakai sistem jadi untuk bagian yang bukan keunggulan Anda. Tidak ada bisnis yang menang karena membangun sendiri modul absensinya.
- Bayar bertahap berdasarkan pencapaian yang bisa diperiksa, bukan berdasarkan tanggal.
- Minta uji coba dengan data nyata sebelum kontrak besar. Ini menemukan masalah ketika memperbaikinya masih murah.
Pertanyaan yang Sering Diajukan
Tim MDH terbiasa memetakan proses lebih dulu, menunjukkan bagian mana yang cukup memakai sistem jadi, dan mana yang benar-benar layak dibuat khusus. Konsultasi awal tanpa biaya.
Diskusikan Kebutuhan Anda
