# Fitur yang Kami Tolak Bangun > Klien minta aplikasi customer. Audit bilang pembelinya tidak akan install. Yang kami bangun sebagai gantinya, dan cara menilai fitur sebelum bayar. Canonical: https://www.ervandra.com/id/blog/the-feature-we-refused-to-build Author: Ervandra Halim Date: 2026-07-20 Baris paling mahal dalam budget software biasanya fitur yang tidak pernah ditanyakan ke pelanggan. Ini cerita tentang satu fitur yang kami tolak bangun, dan kerangka memutuskan apa yang tidak dibangun yang lahir dari engagement seperti ini. Sebuah klien distribusi datang dengan permintaan jelas dan budget sehat: aplikasi mobile untuk pelanggan, supaya para pembeli retail bisa melihat katalog, memesan, dan melacak pengiriman. Kompetitor sedang "go digital". Owner ingin aplikasinya rilis dalam enam bulan. Kami bilang tidak. Bukan pada tujuannya, pada fiturnya. ## Permintaannya: aplikasi yang tidak akan pernah di-install pembeli Permintaan itu berdiri di atas satu asumsi: ratusan pembeli retail kecil akan meng-install, mempelajari, dan terus memakai aplikasi khusus dari satu di antara sekian banyak supplier mereka. Auditnya tidak sampai dua minggu dan sebagian besar berisi mengamati bagaimana order sebenarnya masuk. Semuanya lewat WhatsApp: foto daftar belanja tulisan tangan, voice note, pesan ke nomor pribadi sales. Para pembeli adalah pemilik toko yang menangani puluhan supplier. Tidak satu pun pernah meng-install aplikasi supplier untuk memesan, dan ketika ditanya langsung, jawabannya tegas: tidak akan. Alat pemesanan mereka adalah chat yang sudah mereka tinggali setiap hari. Aplikasi itu akan rilis tepat waktu, tampil memukau saat demo, lalu mati pelan-pelan. Masalahnya memang bukan ketiadaan aplikasi. Masalahnya order WhatsApp masuk tanpa struktur, diketik ulang manual ke back office, dan menghasilkan error serta keterlambatan di setiap langkah. ## Bagaimana cara mengaudit fitur sebelum membangunnya? Audit fitur menjawab tiga pertanyaan dengan bukti, bukan opini: siapa yang benar-benar akan memakainya dan apa yang mereka pakai sekarang, angka bisnis mana yang berubah kalau fitur ini berhasil, dan apa cara termurah menguji asumsi paling berisiko. Metode lengkapnya kami tulis di [seberapa kecil MVP seharusnya](/blog/mvp-how-small-should-you-start), tapi versi pendeknya muat dalam satu kalimat: amati perilaku hari ini lebih dulu, karena pelanggan jauh lebih enggan ganti alat daripada yang diharapkan owner. Diterapkan di kasus ini: penggunanya pemilik toko sibuk dengan kebiasaan WhatsApp yang mengakar, angka yang penting adalah waktu proses order dan tingkat error, dan asumsi paling berisiko adalah install-dan-retensi, yang gugur lewat wawancara di minggu pertama. Audit tidak menyuruh kami membangun nol. Audit menunjukkan di mana budget yang sama benar-benar menghasilkan return. > Satu ide fitur yang kuat bukan strategi produk, dan fitur yang pertama diminta klien jarang sekali sama dengan masalah yang ditemukan audit, kata Ervandra Halim. ## Yang kami bangun sebagai gantinya Scope pengganti mempertahankan WhatsApp sebagai permukaan yang dilihat pelanggan, karena di situlah pelanggan sudah berada, lalu menyelesaikan masalah data terstruktur di belakangnya: katalog yang bisa dibagikan tim sales sebagai link di dalam chat, alur intake yang mengubah pesan masuk menjadi baris order terstruktur untuk dikonfirmasi, dan dashboard internal tempat back office melihat semua order dalam satu antrean, bukan di enam ponsel pribadi. Biayanya kira-kira sepertiga budget aplikasi, dengan waktu pengerjaan jauh lebih singkat. Adopsi tidak pernah jadi pertanyaan, karena tidak ada yang harus mengubah cara memesan. Error turun karena pengetikan ulang hilang, dan owner mendapatkan visibilitas yang sejak awal menjadi motif sebenarnya di balik ide aplikasi itu. Bentuk yang sama kami temui di engagement lain, termasuk [alur pemesanan distributor grosir](/blog/wholesale-distributor-whatsapp-ordering-case-study) yang dibangun di atas prinsip serupa. ## Kenapa bilang tidak adalah keputusan produk, bukan keputusan teknis Tidak ada yang salah secara teknis dari aplikasi itu. Ia bisa dibangun, bisa dihargai, bisa dikirim. Menolaknya adalah penilaian produk: soal pengguna, perilaku, dan di titik mana uang berubah menjadi hasil. Ini separuh pekerjaan yang tidak pernah disentuh peran builder murni, dan alasan saya kini menyebut peran saya chief product and technology officer, bukan hanya sisi engineering. Memutuskan apa yang dibangun dan bagaimana membangunnya adalah satu percakapan yang sama, dipegang oleh orang yang sama yang bertanggung jawab atas keduanya. Versi yang tidak nyaman bagi owner: vendor dibayar sama besar entah fiturnya berhasil atau tidak, jadi vendor tidak punya alasan untuk menolak. Ekonomi dari [memilih partner alih-alih vendor](/blog/choose-a-tech-partner-not-a-vendor) ada persis untuk momen ini, saat jawaban yang menguntungkan dan jawaban yang benar menunjuk ke arah berbeda. ## Kapan aplikasi customer memang layak dibangun? Bangun aplikasi khusus ketika audit menunjukkan perilaku pelanggan Anda mendukungnya: ketika frekuensi order cukup tinggi sehingga alur khusus yang lebih cepat mengalahkan chat, ketika pelanggan berinteraksi dengan Anda harian dan bukan mingguan, atau ketika Anda butuh kemampuan yang memang tidak bisa hidup di chat, seperti harga khusus per akun dalam skala besar atau pekerjaan lapangan offline. Beberapa klien kami sudah melewati garis itu dan membangun aplikasi yang layak; [keputusan build versus buy](/blog/build-vs-buy-software-decision-2025) membahas cara kami menghitung panggilan itu. Urutannya adalah seluruh pelajarannya. Perilaku dulu, struktur kedua, permukaan khusus paling akhir. Kebanyakan budget digital UKM mati karena menjalankan urutan itu terbalik. Kalau Anda ingin penilaian seperti ini diterapkan ke roadmap Anda sebelum budget terlanjur keluar, persis itu yang menjadi awal [sebuah partnership](/partner): audit, dan keberanian mengatakan apa yang tidak perlu dibangun.