5 Pertanyaan Sebelum Memilih Software House

Memilih software house bukan keputusan kecil. Anda menitipkan budget, timeline, dan sering kali bagian penting dari operasional bisnis kepada tim di luar perusahaan. Sayangnya, banyak pemilik bisnis memilih vendor hanya dari presentasi yang meyakinkan dan penawaran harga paling murah, lalu baru menyadari masalahnya setelah proyek berjalan tiga bulan.

Kabar baiknya, sebagian besar masalah itu bisa diprediksi dan bisa dideteksi sebelum Anda tanda tangan kontrak. Berikut lima pertanyaan yang layak Anda ajukan ke setiap software house, lengkap dengan contoh jawaban yang baik dan tanda bahaya yang perlu diwaspadai.

1. Pernah mengerjakan proyek serupa? Boleh saya bicara dengan klien sebelumnya?

Kenapa penting

Portofolio menunjukkan apa yang bisa dibuat sebuah tim. Tapi portofolio tidak selalu menunjukkan bagaimana tim itu bersikap saat deadline mundur, kebutuhan berubah, atau ada error di production. Pengalaman yang relevan mempersingkat proses belajar, dan ngobrol langsung dengan klien sebelumnya memberi gambaran nyata seperti apa rasanya bekerja sama dengan mereka.

"Serupa" tidak harus berarti satu industri. Checkout e-commerce, ERP multi-tenant, dan marketplace berbasis peta punya tantangan yang berbeda. Tanyakan proyek yang karakternya mirip dengan kebutuhan Anda: aplikasi untuk pelanggan, sistem internal, fitur berbasis AI, dan sebagainya.

Jawaban yang baik

• Mereka menunjukkan produk live yang bisa Anda buka sendiri, bukan sekadar mockup.
• Mereka menjelaskan masalah klien, peran mereka, dan keputusan teknis yang diambil, termasuk jujur soal apa yang akan mereka lakukan secara berbeda.
• Mereka bersedia menghubungkan Anda dengan klien sebelumnya, atau menjelaskan dengan jelas jika ada klien yang terikat NDA.

Tanda bahaya

• Hanya ada screenshot, tanpa link live dan tanpa penjelasan apa yang sebenarnya mereka kerjakan.
• Klaim umum seperti "sudah dipercaya ratusan perusahaan" tanpa bukti apa pun.
• Selalu menghindar ketika diminta referensi klien.

2. Siapa saja yang akan mengerjakan proyek saya, dan bagaimana cara kita berkomunikasi?

Kenapa penting

Orang yang hadir di meeting sales sering kali bukan orang yang menulis kode Anda. Mengetahui siapa saja anggota tim dan seberapa banyak waktu mereka dialokasikan untuk proyek Anda akan sangat memengaruhi kualitas dan kecepatan. Komunikasi adalah separuh lainnya. Banyak proyek gagal bukan karena kodenya buruk, tapi karena ekspektasi pelan-pelan bergeser selama berminggu-minggu tanpa ada yang sadar.

Jawaban yang baik

• Ada satu PIC yang jelas (project manager atau lead developer) yang bertanggung jawab atas proyek Anda sehari-hari.
• Gambaran tim yang transparan: peran, tingkat senioritas, dan apakah ada anggota yang juga memegang proyek lain.
• Ritme kerja yang terdefinisi, misalnya progress update mingguan, demo rutin dari fitur yang sudah jalan, dan grup chat untuk pertanyaan cepat.
• Akses ke staging environment sehingga Anda bisa melihat progres sendiri, bukan hanya mendengar laporan.

Tanda bahaya

• "Nanti tim kami yang handle" tanpa nama dan peran yang jelas.
• Pekerjaan diam-diam dilempar ke pihak ketiga yang tidak pernah Anda kenal.
• Update baru datang kalau Anda tagih, atau berminggu-minggu tidak ada hasil yang bisa dilihat.

3. Bagaimana kalau ada perubahan scope, dan bagaimana skema harganya?

Kenapa penting

Kebutuhan Anda pasti berubah. Anda akan dapat masukan dari pengguna awal, menemukan alur kerja yang lebih baik, atau sadar ada fitur yang ternyata tidak terlalu penting. Itu wajar. Yang perlu dipastikan adalah apakah vendor punya cara yang adil dan transparan untuk menanganinya, atau setiap perubahan justru berujung tagihan tak terduga dan kualitas yang diam-diam dikorbankan.

Jawaban yang baik

• Scope tertulis dengan deliverable yang jelas, plus daftar eksplisit tentang apa yang tidak termasuk.
• Proses change request yang sederhana: Anda jelaskan perubahannya, mereka hitung dampaknya ke biaya dan timeline, dan pekerjaan baru jalan setelah Anda setuju.
• Model harga yang sesuai kondisi Anda, entah fixed price untuk scope yang sudah jelas atau time-and-materials untuk proyek yang masih eksploratif, disertai penjelasan jujur soal plus-minus masing-masing.
• Pembayaran per milestone yang hasilnya bisa Anda verifikasi.

Tanda bahaya

• Penawaran yang jauh lebih murah dari vendor lain tanpa penjelasan yang masuk akal.
• "Detailnya nanti saja" untuk hal-hal yang memengaruhi biaya.
• Minta DP besar di awal sebelum ada software yang bisa dicoba.

Penawaran murah dengan scope yang kabur jarang benar-benar murah. Biayanya hanya dipindah ke belakang, saat posisi tawar Anda sudah lebih lemah.

4. Siapa pemilik source code dan hak kekayaan intelektualnya? Di-hosting di mana?

Kenapa penting

Ini pertanyaan yang paling sering terlupa, padahal dampaknya paling terasa kalau ada masalah. Kalau source code bukan milik Anda, akan sulit berganti vendor, membangun tim internal, atau menunjukkan codebase ke investor saat due diligence. Hosting juga krusial: kalau server terdaftar di akun vendor, secara praktis merekalah yang menentukan apakah produk Anda tetap online.

Jawaban yang baik

• Kontrak menyebutkan dengan tegas bahwa source code dan IP menjadi milik Anda setelah pembayaran yang disepakati lunas.
• Kode disimpan di repository yang bisa Anda akses (atau diserahterimakan ke Anda), bukan hanya di laptop developer.
• Hosting, domain, dan akun layanan pihak ketiga didaftarkan atas nama perusahaan Anda, atau ada rencana serah terima yang jelas.
• Dokumentasi yang memadai, sehingga developer lain bisa melanjutkan proyek bila diperlukan.

Tanda bahaya

• Status kepemilikan "nanti dibicarakan" atau terselip di pasal kecil kontrak.
• Platform atau framework proprietary yang hanya bisa dipelihara oleh vendor tersebut.
• Menolak memberi akses repository atau server.

5. Apa yang terjadi setelah aplikasi live?

Kenapa penting

Hari peluncuran bukan garis finis. Pengguna nyata akan menemukan bug, sistem operasi terus diperbarui, patch keamanan rutin dirilis, dan bisnis Anda sendiri terus berkembang. Vendor yang menghilang sehari setelah go-live meninggalkan Anda dengan software yang tidak bisa diubah dengan aman.

Jawaban yang baik

• Ada masa garansi setelah peluncuran, di mana bug pada scope yang disepakati diperbaiki tanpa biaya tambahan, dan durasinya tertulis di kontrak.
• Opsi maintenance yang jelas untuk update rutin, monitoring, dan penyempurnaan kecil.
• Untuk sistem yang kritikal bagi bisnis, ada SLA yang mengatur waktu respons dan definisi kondisi darurat.
• Serah terima yang rapi: kredensial, dokumentasi, dan sesi walkthrough untuk tim Anda.

Tanda bahaya

• Tidak pernah menyinggung soal support sampai Anda bertanya, lalu hanya memberi janji yang samar.
• Setiap perbaikan setelah launch ditagih sebagai proyek baru.
• Tidak ada monitoring maupun backup saat aplikasi mulai live.

---

Bagaimana CodeWorks menjawab pertanyaan-pertanyaan ini

Kami justru senang kalau calon klien menanyakan hal-hal di atas. Singkatnya, begini posisi kami:

1. Portofolio: proyek kami mencakup aplikasi mobile, platform web, ERP multi-tenant, toko online, hingga location intelligence berbasis AI, dan banyak di antaranya adalah produk live yang bisa Anda buka langsung di halaman portofolio kami. [CONFIRM: apakah klien sebelumnya bersedia dijadikan referensi, dan bagaimana cara memintanya]
2. Tim dan komunikasi: [CONFIRM: siapa PIC utama klien, komposisi tim yang umum, dan ritme update/demo]
3. Scope dan harga: [CONFIRM: model harga yang ditawarkan (fixed / time-and-materials), proses change request, dan termin pembayaran]
4. Kepemilikan kode: [CONFIRM: ketentuan kepemilikan IP/source code dan apakah hosting serta repository dibuat atas akun klien]
5. Setelah launch: [CONFIRM: durasi masa garansi, paket maintenance, dan ketersediaan SLA]

Siapa pun vendor yang akhirnya Anda pilih, gunakan lima pertanyaan ini. Partner yang baik tidak akan keberatan menjawabnya.

Sedang merencanakan proyek dan ingin jawaban yang jujur untuk pertanyaan-pertanyaan di atas? Hubungi CodeWorks untuk ngobrol santai, tanpa kewajiban apa pun.