Kenapa Harga Aplikasi Custom Bisa Beda Jauh Antar Vendor

Anda mengirim brief yang sama ke tiga vendor. Penawaran yang masuk selisihnya berkali lipat. Ada yang murah sekali, ada yang terasa mahal, dan semuanya sama-sama bilang sanggup mengerjakan apa yang Anda minta. Jawaban singkatnya begini. Harga aplikasi custom bisa beda jauh karena empat hal utama: scope yang ditafsirkan berbeda, siapa yang mengerjakan, kualitas yang tidak kelihatan saat demo, dan layanan setelah aplikasi rilis.

Kami menulis ini dari posisi orang dalam. Kami pernah kalah tender karena penawaran kami dianggap kemahalan. Kami juga pernah diminta membenahi aplikasi murah yang ujungnya lebih mahal daripada membangun ulang dari awal. Artikel ini membedah satu per satu faktor yang membuat penawaran bisa selisih jauh, supaya Anda bisa membandingkan dengan adil, bukan sekadar memilih angka terkecil.

Scope yang sama di brief, beda jauh di kepala vendor

Ini penyebab paling sering. Istilah seperti “aplikasi kasir” atau “aplikasi manajemen stok” itu bukan satu barang yang bakunya sama di semua tempat. Satu vendor membacanya sebagai 10 fitur. Vendor lain membacanya sebagai 40 fitur. Keduanya jujur, tapi mereka menghitung barang yang berbeda.

Contoh nyata. Aplikasi kasir versi sederhana isinya input barang, catat transaksi, cetak struk. Versi lengkapnya bisa punya multi cabang, manajemen stok dengan stok opname, laporan laba rugi, hak akses per karyawan, integrasi pembayaran digital, sampai mode offline saat internet mati. Nama di proposal sama-sama “aplikasi kasir”. Beban kerjanya bisa beda empat kali lipat.

Kalau brief Anda hanya satu paragraf, setiap vendor akan mengisi kekosongannya dengan asumsi masing-masing. Vendor yang menawar murah mungkin berasumsi versi minimal. Vendor yang menawar mahal mungkin sudah menghitung skenario lengkap. Selisih harga di tahap ini belum tentu soal mahal atau murah. Sering kali itu soal dua tafsir yang tidak pernah disamakan.

Siapa yang mengerjakan: satu orang atau satu tim

Faktor kedua adalah struktur orang di baliknya. Freelancer solo bisa menawar jauh lebih murah karena semua peran dia pegang sendiri. Dia yang desain, dia yang koding, dia yang tes, dia juga yang balas chat Anda. Tidak ada biaya tim yang harus ditanggung.

Vendor dengan tim menghitung beberapa orang sekaligus. Developer yang menulis kode, QA yang mencari bug sebelum Anda yang menemukannya, dan project manager yang menjaga jadwal serta jadi jembatan komunikasi. Setiap peran itu digaji, dan gaji itu masuk ke harga penawaran Anda.

Konsekuensinya nyata, bukan sekadar teori. Aplikasi yang dites hanya oleh pembuatnya sendiri hampir selalu lolos dengan bug yang tidak dia sadari, karena dia mengetes dengan cara dia memakai, bukan cara user memakai. Dan kalau freelancer tunggal sakit, pindah kerja, atau menghilang di tengah proyek, tidak ada orang kedua yang paham kodenya. Proyek berhenti total. Di tim, ada orang lain yang bisa melanjutkan.

Bukan berarti freelancer selalu pilihan buruk. Untuk aplikasi kecil dengan risiko rendah, freelancer yang bagus bisa sangat masuk akal. Tapi untuk sistem yang dipakai operasional harian bisnis Anda, sebagian dari selisih harga itu adalah harga dari tidak bergantung pada satu orang.

Kualitas yang tidak kelihatan di demo

Dua aplikasi bisa terlihat identik saat demo. Tampilan mirip, fitur jalan, tombol berfungsi. Yang membedakan harganya justru hal-hal yang tidak muncul di layar presentasi.

Pertama, keamanan. Apakah password disimpan dengan benar, apakah aplikasi tahan terhadap serangan umum seperti SQL injection, apakah data pelanggan Anda tidak bocor lewat celah yang sudah lama dikenal. Mengerjakan ini butuh waktu dan keahlian, dan hasilnya tidak kelihatan sama sekali sampai ada insiden.

Kedua, backup dan pemulihan. Aplikasi murah sering tidak punya backup otomatis. Semuanya baik-baik saja sampai server bermasalah dan data transaksi bertahun-tahun hilang dalam satu malam.

Ketiga, kemampuan menangani banyak user. Aplikasi yang lancar dipakai dua orang saat demo bisa melambat parah saat dipakai lima puluh kasir di jam sibuk. Membuat aplikasi yang kuat di beban tinggi butuh arsitektur yang dipikirkan sejak awal, bukan tambalan belakangan.

Keempat, kode yang bisa dirawat. Kode yang rapi dan terdokumentasi membuat penambahan fitur di tahun kedua jadi murah dan cepat. Kode yang asal jadi membuat setiap perubahan kecil terasa seperti operasi besar, dan sering kali developer lain menolak menyentuhnya. Anda tidak bisa melihat perbedaan ini di demo. Anda baru merasakannya setahun kemudian.

Teknologi dan infrastruktur di baliknya

Cara vendor membangun aplikasi juga sangat menentukan harga. Ada vendor yang memakai template jadi atau platform no-code, lalu menyesuaikan seperlunya. Ada yang membangun dari nol sesuai proses bisnis Anda. Keduanya sah, tapi harganya jelas beda jauh.

Template dan no-code cepat dan murah di awal. Cocok kalau kebutuhan Anda memang standar. Masalah muncul kalau proses bisnis Anda tidak persis sama dengan asumsi template. Anda yang akhirnya menyesuaikan cara kerja ke aplikasinya, bukan sebaliknya. Beberapa platform no-code juga mengikat Anda pada biaya langganan yang terus berjalan, dan aplikasi tidak bisa dipindah keluar dari platform itu.

Bangun dari nol lebih mahal karena semua dibuat mengikuti alur kerja Anda. Tapi hasilnya milik Anda sepenuhnya dan bisa dikembangkan ke arah mana pun.

Infrastruktur juga sering luput dari perbandingan. Server yang layak untuk aplikasi bisnis, dengan spesifikasi cukup, monitoring, dan backup, biayanya berbeda jauh dengan hosting murah yang sebenarnya untuk website profil. Sebagian vendor memasukkan biaya server yang layak ke penawaran. Sebagian memakai yang paling murah supaya angka penawarannya menang. Angka totalnya jadi tidak sebanding, padahal kelihatannya sama-sama “sudah termasuk server”.

Layanan setelah rilis, dan apa yang dipotong vendor banting harga

Aplikasi itu bukan proyek yang selesai saat serah terima. Bug pasti ada, kebutuhan pasti berkembang, dan sistem bisa mati di waktu yang paling tidak enak. Di sinilah penawaran antar vendor sering beda isi walau beda harganya tidak kelihatan di halaman depan proposal.

Hal yang perlu Anda cek: berapa lama garansi bug setelah rilis, apakah ada paket maintenance bulanan, dan seberapa cepat vendor merespons kalau sistem down saat operasional. Vendor yang menjanjikan respons cepat harus menyiapkan orang untuk siaga, dan itu ada biayanya. Vendor yang tidak menjanjikan apa-apa memang bisa lebih murah, karena setelah serah terima Anda pada dasarnya sendirian.

Lalu soal banting harga. Kami akan jujur di sini, karena polanya hampir selalu sama. Vendor yang menawar jauh di bawah pasar jarang memotong fitur, karena fitur itu yang dilihat klien. Yang dipotong adalah hal-hal yang tidak kelihatan: waktu testing dipangkas, dokumentasi tidak dibuat, keamanan dikerjakan seadanya, backup dilewati, dan kode ditulis secepatnya tanpa memikirkan perawatan.

Risikonya jatuh ke Anda, bukan ke vendor. Aplikasi tetap terlihat jadi di hari serah terima. Masalahnya muncul tiga sampai enam bulan kemudian, saat bug bermunculan, data bermasalah, dan vendor aslinya sudah sulit dihubungi. Beberapa klien kami datang persis di titik ini, dan biaya membenahinya sering lebih besar dari selisih harga yang dulu dihemat. Murah di depan bisa jadi mahal di belakang. Bukan karena semua vendor murah nakal, tapi karena angka yang terlalu rendah memang tidak cukup untuk membayar pekerjaan yang utuh.

Cara membandingkan penawaran secara adil

Setelah tahu faktor-faktor di atas, cara membandingkannya jadi lebih jelas. Intinya satu: pastikan Anda membandingkan barang yang sama.

• Samakan scope secara tertulis. Buat daftar fitur yang rinci, termasuk jumlah user, jumlah cabang, dan laporan apa saja yang dibutuhkan. Kirim daftar yang sama ke semua vendor dan minta penawaran mengacu ke daftar itu, bukan ke tafsir masing-masing.
• Tanya apa yang tidak termasuk. Ini pertanyaan yang paling jarang diajukan dan paling banyak membongkar. Apakah testing termasuk. Apakah server dan domain termasuk, dan untuk berapa lama. Apakah training user termasuk. Apakah revisi setelah rilis termasuk, dan sampai kapan.
• Tanya siapa yang mengerjakan. Satu orang atau tim. Kalau tim, siapa saja perannya. Kalau orang kuncinya berhalangan, siapa penggantinya.
• Tanya soal garansi dan maintenance. Berapa lama garansi bug, berapa biaya maintenance setelahnya, dan berapa lama waktu respons kalau sistem mati.
• Tanya siapa yang memegang source code. Pastikan sejak awal bahwa source code diserahkan ke Anda, bukan ditahan vendor. Detail apa saja yang harus Anda terima saat proyek selesai sudah kami tulis lengkap di checklist serah terima proyek aplikasi dari vendor.

Dengan lima hal itu tertulis hitam di atas putih, selisih harga antar vendor biasanya langsung bisa dijelaskan. Anda akan lihat vendor mana yang murah karena memang scope-nya kecil, dan mana yang murah karena ada yang dipotong diam-diam.

Kalau Anda sedang membandingkan penawaran dan ingin pembanding yang jelas isinya, silakan lihat layanan pembuatan sistem aplikasi kami. Kami terbiasa merinci scope, apa yang termasuk dan tidak termasuk, serta skema garansi sejak awal. Atau kalau mau lebih cepat, hubungi kami dan bawa penawaran yang sudah Anda terima. Kami bisa bantu membacanya, bahkan kalau akhirnya Anda memilih vendor lain.