Checklist Memilih Software House di Indonesia: 12 Pertanyaan Penting

Memilih vendor untuk membangun aplikasi itu seperti memilih kontraktor rumah: hasilnya kamu pakai bertahun-tahun, tapi keputusannya sering diambil dari satu-dua pertemuan dan selembar penawaran. Artikel ini adalah checklist memilih software house yang kami susun supaya kamu bisa mengevaluasi vendor mana pun secara adil, termasuk mengevaluasi kami sendiri.

Ada 12 pertanyaan. Tidak semua harus dijawab sempurna, tapi setiap jawaban memberi tahu banyak hal tentang cara kerja vendor tersebut.

12 pertanyaan sebelum tanda tangan

1. Siapa persisnya yang akan mengerjakan proyek saya?

Tanyakan nama dan peran orang yang benar-benar menulis kode dan mendesain, bukan hanya nama orang sales. Tanyakan juga: apakah pekerjaan ini dikerjakan tim internal atau dilempar ke pihak ketiga? Pekerjaan yang di-outsource lagi bukan selalu buruk, tapi kamu berhak tahu, karena itu memengaruhi kualitas komunikasi dan tanggung jawab.

2. Boleh lihat produk yang pernah kalian bangun?

Portofolio berupa daftar logo klien mudah dibuat. Yang lebih sulit dipalsukan: produk yang bisa kamu buka dan coba sendiri. Vendor yang membangun produk sendiri (bukan hanya proyek klien) biasanya lebih paham rasanya merawat aplikasi jangka panjang, karena mereka menanggung sendiri akibat dari keputusan teknis yang buruk.

3. Bagaimana proses kerjanya, dan seberapa sering saya melihat progres?

Jawaban yang sehat menyebutkan tahapan yang jelas dan ritme demo yang rutin, misalnya mingguan. Kalau jawabannya "nanti kami kabari kalau sudah jadi", ini risiko besar: kamu baru tahu ada yang salah setelah tiga bulan. Gambaran tahapan yang wajar bisa kamu baca di SDLC untuk pemilik bisnis.

4. Siapa pemilik source code, repository, dan akun?

Ini pertanyaan yang paling sering terlewat dan paling mahal akibatnya. Pastikan secara tertulis:

• Source code dan repository menjadi milik bisnismu setelah pembayaran selesai.
• Domain, hosting, akun cloud, akun app store, dan layanan pihak ketiga dibuat atas nama bisnismu, bukan atas nama vendor.
• Kamu punya akses admin ke semuanya, bukan hanya vendor.

Kalau suatu hari kamu ingin ganti vendor, ini yang menentukan apakah prosesnya seminggu atau bencana.

5. Apa yang saya terima selain aplikasinya?

Dokumentasi teknis, cara deploy, struktur database, dan daftar akun. Tanpa ini, vendor berikutnya (atau tim internalmu nanti) harus menebak-nebak. Minta contoh dokumentasi dari proyek sebelumnya kalau memungkinkan.

6. Bagaimana cara kalian menguji aplikasinya?

Jawaban "kami tes manual sebelum kirim" saja tidak cukup untuk aplikasi yang akan dipakai bertahun-tahun. Tanyakan apakah ada pengujian otomatis, review kode antar anggota tim, dan apa yang terjadi kalau ada bug setelah rilis. Vendor yang menganggap testing sebagai bagian default, bukan biaya tambahan, biasanya menghasilkan aplikasi yang lebih stabil.

7. Bagaimana estimasi dibuat, dan bagaimana cara bayarnya?

Dua model yang umum:

Keduanya sah. Yang bermasalah adalah harga tetap untuk scope yang belum jelas: salah satu pihak pasti rugi. Minta rincian apa yang termasuk dalam harga: desain, pengujian, deploy, pelatihan, berapa kali revisi. Soal struktur biaya lebih dalam, baca biaya bikin aplikasi di Indonesia 2026.

8. Apa yang terjadi setelah aplikasi rilis?

Aplikasi tidak selesai saat rilis. Sistem operasi diperbarui, layanan pihak ketiga berubah, bug baru ditemukan. Tanyakan: ada masa garansi perbaikan bug? Berapa lama? Setelah itu, bagaimana skema maintenance dan berapa biayanya? Vendor yang tidak punya jawaban untuk ini mungkin tidak berencana ada saat kamu membutuhkannya.

9. Bagaimana data pelanggan saya dijaga?

Tanyakan di mana data disimpan, siapa yang punya akses, bagaimana password dan data sensitif dienkripsi, dan apakah ada backup rutin. Kalau proyekmu melibatkan AI, tanyakan juga data apa yang dikirim ke penyedia model AI. Vendor yang serius akan punya jawaban konkret, bukan "aman kok".

10. Bagaimana komunikasinya sehari-hari?

Lewat apa (WhatsApp, email, tool manajemen proyek)? Seberapa cepat biasanya dibalas? Apakah kamu bisa bicara langsung dengan engineer, atau selalu lewat perantara? Komunikasi yang lambat atau berlapis adalah sumber paling umum dari proyek yang molor.

11. Kalau kerja sama berhenti, apa yang terjadi?

Pertanyaan yang tidak enak ditanyakan, tapi penting. Apakah ada proses serah terima? Apakah kode dan akun diserahkan dalam kondisi bisa dilanjutkan vendor lain? Apakah ada biaya "tebusan"? Vendor yang percaya diri dengan kualitas kerjanya tidak akan keberatan dengan pertanyaan ini.

12. Untuk proyek AI: apa yang pernah kalian bangun dengan AI, dan apa batasnya?

Kalau proyekmu melibatkan AI, tanyakan pengalaman nyata mereka: produk apa yang pernah mereka bangun dengan LLM, bagaimana mereka menangani jawaban yang salah, dan bagaimana mereka mengukur akurasi. Hati-hati dengan vendor yang menjanjikan AI "100% akurat" atau "bisa segalanya". Vendor yang jujur akan menjelaskan batasnya, seperti yang kami tulis di chatbot AI WhatsApp dan RAG untuk dokumen bisnis.

Catatan jujur: kami juga tidak sempurna di semua poin ini. Sebagai perusahaan yang masih muda, portofolio proyek klien kami belum panjang; yang bisa kami tunjukkan adalah produk yang kami bangun sendiri, Cuplikin dan KosPro, serta cara kerja kami yang terbuka. Kami lebih memilih kamu tahu ini sejak awal daripada menemukannya belakangan.

Red flag yang perlu diwaspadai

Beberapa tanda yang menurut kami layak membuat kamu berpikir dua kali:

• Harga diberikan dalam 10 menit tanpa bertanya detail. Estimasi yang baik butuh pemahaman scope.
• Semua fitur dijawab "bisa". Tidak ada vendor yang bisa semuanya. Yang jujur akan bilang mana yang mudah, mana yang sulit, dan mana yang sebaiknya tidak dilakukan.
• Menolak memberi akses ke repository atau akun. Ini tanda ketergantungan yang disengaja.
• Tidak ada demo atau progres yang bisa dilihat selama berminggu-minggu.
• Menekan untuk segera tanda tangan dengan diskon yang "hanya berlaku hari ini".
• Tidak bisa menjelaskan keputusan teknis dalam bahasa yang kamu pahami. Bukan berarti kamu harus paham semua, tapi vendor yang baik bisa menjelaskan "kenapa" dengan sederhana.
• Tidak pernah bilang "tidak". Vendor yang menyetujui semua permintaan di tengah jalan tanpa bicara soal dampaknya ke timeline atau biaya sedang menyimpan masalah untuk nanti.

Cara membandingkan penawaran secara adil

Tiga penawaran dengan angka Rp 40 juta, Rp 90 juta, dan Rp 200 juta untuk "aplikasi yang sama" hampir pasti bukan aplikasi yang sama. Supaya adil:

1. Samakan scope-nya. Tulis alur pengguna inti dan daftar fitur Must/Should/Could, lalu kirim dokumen yang sama ke semua vendor. Cara menyusunnya ada di MVP vs produk lengkap.
2. Buat tabel perbandingan apa yang termasuk. Desain, pengujian, deploy, dokumentasi, pelatihan, garansi, maintenance. Tanda centang dan silang lebih jujur daripada angka total.
3. Bandingkan asumsi, bukan hanya harga. Vendor yang menulis asumsinya dengan jelas ("integrasi pembayaran memakai satu penyedia", "maksimal 3 revisi desain") lebih bisa dipegang daripada yang menulis satu angka saja.
4. Hitung biaya 2–3 tahun, bukan hanya biaya bangun. Maintenance, server, langganan pihak ketiga. Penawaran murah dengan maintenance mahal bisa lebih mahal totalnya.
5. Perhatikan kualitas pertanyaan mereka. Vendor yang banyak bertanya tentang bisnismu sebelum memberi harga biasanya lebih paham apa yang akan mereka bangun.

Freelancer, software house, atau tim internal?

Supaya lengkap, software house bukan satu-satunya pilihan:

Untuk UMKM yang belum punya orang teknis di dalam, software house atau freelancer berpengalaman dengan proses yang jelas biasanya pilihan paling masuk akal. Tim internal masuk akal setelah produknya terbukti dan butuh pengembangan terus-menerus.

Langkah selanjutnya

Simpan 12 pertanyaan di atas dan ajukan ke setiap vendor yang kamu pertimbangkan, termasuk ke kami. Kalau kamu ingin mencoba, ceritakan rencana aplikasimu lewat konsultasi awal yang gratis, dan tanyakan apa pun dari daftar ini. Lihat layanan kami, lalu kirim pesan lewat form kontak atau chat via WhatsApp.