Kamu chat sebuah software house. Pertanyaannya sederhana, “berapa harga bikin aplikasi kasir?” Balasannya malah sepuluh pertanyaan. Siapa penggunanya, prosesnya sekarang bagaimana, mau integrasi apa saja. Rasanya seperti dipersulit. Padahal kamu cuma mau tahu angka kasar buat bandingin, belum tentu jadi juga.
Jawaban singkatnya begini. Harga sistem custom itu turunan dari scope, dan scope tidak bisa ditebak dari satu kalimat “mau bikin aplikasi kasir”. Developer yang banyak bertanya sedang memastikan kamu membayar untuk hal yang benar benar kamu butuhkan, tidak kurang dan tidak lebih. Justru vendor yang berani sebut angka pasti dalam lima menit chat, tanpa bertanya apa apa, yang patut kamu curigai. Artikel ini membedah kenapa.
Harga sistem custom itu turunan dari scope, bukan tarif menu
Aplikasi kasir untuk satu warung kopi dengan satu kasir dan aplikasi kasir untuk 12 cabang minimarket itu dua proyek yang beda jauh. Namanya sama. Isinya tidak.
Yang satu cukup satu perangkat, data lokal, laporan harian sederhana. Yang satu lagi butuh sinkronisasi antar cabang, manajemen stok terpusat, hak akses berlapis, dan server yang sanggup dipakai puluhan orang bersamaan. Selisih biayanya bisa berkali kali lipat.
Dari kalimat “mau bikin aplikasi kasir”, developer belum tahu kamu ada di posisi yang mana. Kalau dia langsung sebut angka, dia sedang menebak. Dan tebakan itu nanti dibayar oleh salah satu dari kalian, entah kamu lewat harga yang membengkak, entah dia lewat kerja rugi yang ujungnya memangkas kualitas.
Ini beda dengan beli barang jadi. Harga laptop bisa langsung disebut karena barangnya sudah ada, speknya jelas, tinggal pilih. Sistem custom belum ada wujudnya saat kamu tanya harga. Yang dijual adalah jam kerja orang untuk membangun sesuatu yang bentuknya baru ketahuan setelah kebutuhanmu digali. Makin jelas kebutuhannya, makin akurat angkanya. Sesederhana itu hubungannya.
Ini juga yang menjelaskan kenapa penawaran antar vendor bisa beda jauh untuk permintaan yang kelihatannya sama persis. Bukan selalu karena yang satu mahal dan yang satu murah. Sering kali karena masing masing menebak scope yang berbeda dari brief yang sama samarnya. Yang satu membayangkan sistem sederhana, yang satu lagi membayangkan sistem lengkap dengan laporan dan hak akses. Keduanya menjawab pertanyaan yang sama, tapi menjawab soal yang berbeda di kepala masing masing.
Bedah pertanyaan developer dan alasan di baliknya
Pertanyaan yang terasa cerewet itu sebenarnya punya fungsi teknis masing masing. Ini yang paling sering muncul dan kenapa dia ditanyakan.
“Siapa penggunanya dan berapa banyak?”
Ini menentukan arsitektur dan biaya server. Sistem untuk 5 admin internal bisa jalan di server murah dengan struktur sederhana. Sistem yang dipakai ribuan pelanggan umum butuh desain yang tahan beban, keamanan lebih ketat, dan biaya bulanan yang berbeda kelas. Salah jawab di sini, salah fondasi di semua hal setelahnya.
“Proses kamu sekarang jalannya seperti apa?”
Sistem yang baik meniru alur kerja nyata, bukan alur khayalan. Kalau developer tidak tahu bagaimana barang masuk dicatat, siapa yang menyetujui diskon, atau kapan laporan direkap, dia akan membangun berdasarkan asumsi. Hasilnya aplikasi yang secara teknis jalan tapi tidak dipakai tim, karena tidak cocok dengan cara kerja mereka sehari hari.
“Perlu integrasi dengan apa saja?”
Payment gateway, notifikasi WhatsApp, sistem akuntansi lama, mesin absensi. Integrasi adalah penyumbang biaya terbesar yang paling sering tidak terlihat dari luar. Dari sisi klien rasanya cuma “tinggal disambungkan”. Dari sisi teknis, tiap sambungan berarti mempelajari sistem lain, menangani kegagalan koneksi, dan menjaga data tetap sinkron. Satu integrasi bisa lebih mahal dari beberapa fitur biasa digabung.
“Dari semua ini, mana yang wajib ada di versi pertama?”
Pertanyaan ini memisahkan kebutuhan dari keinginan. Hampir semua klien datang dengan daftar fitur yang lebih panjang dari yang benar benar dibutuhkan untuk mulai jalan. Developer yang baik akan membantu memangkasnya jadi versi pertama yang ramping, lalu menambah bertahap. Pendekatan ini yang biasa disebut MVP, dan kami pernah mengupasnya di artikel apa itu MVP dan kenapa mulai dari versi kecil itu menyelamatkan budget. Tanpa pertanyaan ini, kamu bisa membayar fitur yang setahun kemudian belum pernah dibuka.
“Siapa yang mengambil keputusan akhir?”
Kedengarannya bukan urusan teknis, tapi ini penentu lancarnya proyek. Kalau brief datang dari manajer operasional, lalu di tengah jalan pemilik usaha muncul dengan visi yang berbeda, revisi akan berputar tanpa ujung. Developer bertanya ini supaya kesepakatan dibuat dengan orang yang benar sejak awal, bukan dibongkar di minggu terakhir.
Analogi sederhananya begini
Bayangkan dua dokter. Dokter pertama mendengar kamu bilang “perut saya sakit”, langsung menulis resep tanpa bertanya apa apa. Dokter kedua bertanya dulu, sejak kapan, sakitnya di bagian mana, habis makan apa, lalu memeriksa. Kamu percaya yang mana?
Atau kontraktor rumah. Yang satu berani sebut total biaya bangun rumah tanpa pernah melihat tanahnya, tanpa tahu kontur, akses jalan, atau kondisi tanah keras atau gembur. Yang satu lagi minta survei dulu. Semua orang tahu mana yang lebih bisa dipegang, tapi anehnya di proyek software, vendor yang langsung sebut angka justru sering dianggap lebih sigap.
Pertanyaan developer itu setara dengan pemeriksaan dokter dan survei kontraktor. Bukan basa basi, bukan cara mengulur waktu. Itu bagian dari pekerjaan.
Bendera merah justru vendor yang langsung sebut angka
Kalau ada vendor yang memberi harga pasti untuk sistem custom dalam lima menit chat, biasanya salah satu dari tiga hal ini yang terjadi di belakang.
- Harganya akan berubah di tengah jalan. Angka awal cuma pancingan. Begitu proyek jalan dan detail bermunculan, muncul biaya tambahan demi biaya tambahan. Ini scope creep versi vendor, dan posisimu untuk menolak sudah lemah karena proyek sudah setengah jalan.
- Kualitas dipangkas diam diam. Supaya tetap untung di angka yang dia sebut asal, ada yang dikorbankan tanpa kamu tahu. Biasanya di bagian yang tidak terlihat, seperti keamanan, struktur kode, atau pengujian. Masalahnya baru terasa berbulan bulan kemudian.
- Kamu dikasih template yang dipaksakan. Angkanya bisa pasti karena produknya sudah jadi. Kebutuhanmu yang diminta menyesuaikan, bukan sebaliknya. Untuk kasus tertentu ini sah saja, tapi harus dibilang jujur di depan, bukan dibungkus seolah sistem dibuat khusus untukmu.
Perlu dibedakan juga dengan estimasi kasar. Vendor yang bilang “sistem seperti ini biasanya mulai dari sekian, tapi kami perlu gali dulu untuk angka pastinya” itu wajar dan malah membantu. Yang jadi bendera merah adalah angka pasti yang diklaim final padahal kebutuhanmu belum digali sama sekali.
Jadi kalau selama ini kamu menganggap banyak bertanya sebagai tanda vendor lambat, coba balik kacamatanya. Kecepatan menyebut angka bukan ukuran profesionalisme. Ketepatan memahami kebutuhan yang lebih layak dinilai.
Cara mempercepat proses tanya jawab dari sisimu
Kabar baiknya, proses ini bisa dipersingkat banyak kalau kamu datang dengan persiapan. Tiga hal ini paling berpengaruh.
- Siapkan jawaban sebelum ngobrol. Tulis dulu siapa penggunanya, masalah apa yang mau diselesaikan, proses manual yang sekarang berjalan, dan integrasi yang kamu bayangkan. Kami sudah membuatkan template brief yang bisa kamu isi sebelum ketemu developer. Diskusi yang biasanya butuh tiga kali pertemuan bisa selesai dalam satu.
- Jujur soal budget range. Banyak klien menyembunyikan budget karena takut dimanfaatkan. Padahal efeknya kebalikan. Tanpa gambaran budget, developer tidak tahu harus menawarkan solusi kelas mana, dan bolak balik penawaran jadi panjang. Dengan range yang jelas, dia bisa langsung bilang mana yang masuk akal di angka itu dan mana yang perlu ditunda. Kamu hemat waktu, bukan rugi.
- Tunjuk satu PIC. Satu orang yang memegang komunikasi dan berwenang mengambil keputusan. Keputusan yang lewat banyak pintu adalah sumber revisi berputar dan jadwal molor.
- Bawa contoh yang konkret. Foto form kertas yang sekarang dipakai, tangkapan layar file Excel yang jadi andalan, atau nama aplikasi yang alurnya kamu suka. Satu contoh nyata sering menjelaskan lebih banyak daripada tiga paragraf penjelasan, dan biasanya langsung memangkas beberapa putaran pertanyaan.
Setelah tanya jawab, ini yang wajar kamu terima
Alur yang sehat biasanya begini. Setelah diskusi kebutuhan, developer memberi estimasi berupa range, misalnya kisaran bawah dan atas berdasarkan pemahaman awal. Range di tahap ini bukan tanda ragu, tapi tanda jujur, karena memang masih ada bagian yang belum digali dalam. Setelah scope disepakati lebih rinci, baru keluar penawaran detail berisi daftar fitur, tahapan, jadwal, dan harga yang mengikat.
Kalau kamu membandingkan beberapa vendor, bandingkan di tahap penawaran rinci ini, bukan di tahap tebak tebakan awal. Pastikan daftar fiturnya sepadan dulu, baru adu angka. Membandingkan dua penawaran yang scopenya beda itu seperti membandingkan harga rumah tanpa tahu luas bangunannya.
Satu hal yang perlu kamu tahu, estimasi yang berubah saat scope berubah itu normal. Kamu menambah fitur, angkanya naik. Kamu memangkas fitur, angkanya turun. Yang tidak normal adalah angka yang berubah tanpa penjelasan, atau perubahan scope yang tidak pernah dicatat hitam di atas putih. Ukurannya bukan “harga tidak boleh berubah”, tapi “setiap perubahan harus transparan dan disepakati dua pihak”.
Di Arrazy, urutannya memang begitu. Kami ajak diskusi kebutuhan dulu, gratis dan tanpa kewajiban lanjut, baru bicara angka setelah gambaran scopenya jelas. Kalau kamu sedang menimbang bikin sistem dan ingin tahu kisaran biayanya, ceritakan kebutuhanmu lewat halaman kontak. Bawa daftar pertanyaanmu sekalian. Kami juga akan banyak bertanya, dan sekarang kamu tahu kenapa itu justru kabar baik.
