Cara Memilih Software House di Indonesia

Cara memilih software house yang paling aman adalah menilai tiga hal sebelum membandingkan harga: apakah perusahaannya jelas secara hukum, apakah hasil kerjanya bisa Anda buka dan coba sendiri, dan apakah kontraknya menjawab siapa pemilik kode serta apa yang terjadi setelah aplikasi rilis. Software house di Indonesia jumlahnya banyak, dari tim dua orang sampai perusahaan ratusan karyawan. Ukuran tidak menentukan kualitas. Cara mereka bekerja yang menentukan.

Masalah yang membuat proyek software macet biasanya sudah terlihat sejak tahap penawaran. Hanya saja jarang ada yang tahu harus bertanya apa. Daftar di bawah ini adalah pertanyaan yang menurut saya perlu diajukan setiap calon klien, termasuk kepada kami.

1. Pastikan perusahaannya nyata

Software house yang serius punya badan usaha, alamat, dan bisa menerbitkan invoice atas nama perusahaan. Untuk Anda, ini penting karena dua alasan: kontrak hanya bermakna kalau ada pihak yang bisa dimintai tanggung jawab, dan bagian keuangan Anda butuh dokumen yang sah.

Yang bisa Anda cek sendiri:

• Nama PT atau CV dan nomor induk berusaha (NIB). Banyak perusahaan menampilkannya di website. Data kami, misalnya, ada di halaman legalitas.
• Alamat dan nomor yang bisa dihubungi, bukan hanya formulir.
• Siapa orang di baliknya. Profil pendiri atau tim teknis yang bisa ditelusuri.

2. Buka portofolionya, jangan hanya dilihat

Portofolio berupa gambar mockup cantik tidak membuktikan apa-apa. Yang Anda cari adalah produk yang hidup. Klik tautannya. Unduh aplikasinya. Coba daftar, coba checkout. Perhatikan apakah halaman cepat terbuka di HP Anda dan apakah ada yang rusak.

Pertanyaan lanjutan yang berguna: "Bagian mana dari proyek ini yang kalian kerjakan?". Kadang satu proyek dikerjakan beberapa vendor, dan wajar saja, asal jujur. Di portofolio KSATRIA, setiap proyek kami beri tautan ke produknya dan keterangan singkat tentang perannya.

3. Cara memilih software house lewat isi penawarannya

Penawaran yang baik bisa dibaca orang non-teknis dan tetap jelas. Minimal isinya:

• Ruang lingkup. Daftar fitur dan layar yang dikerjakan, sebaiknya dengan kalimat yang bisa diuji, misalnya "admin dapat mengekspor laporan penjualan per bulan ke Excel".
• Yang tidak termasuk. Ini sering lebih penting daripada yang termasuk. Konten, foto, biaya server, akun toko aplikasi, biaya pihak ketiga.
• Jadwal per tahap dengan titik demo yang jelas.
• Cara menangani perubahan. Perubahan di tengah jalan itu normal. Yang tidak normal adalah tidak ada aturan bagaimana perubahan dihitung.
• Masa garansi. Berapa lama bug diperbaiki gratis setelah rilis.

Harga tetap atau dihitung per waktu kerja?

Harga tetap cocok untuk pekerjaan yang ruang lingkupnya jelas, misalnya website company profile atau MVP dengan fitur yang sudah dikunci. Itu sebabnya kami menjual beberapa paket dengan harga tetap di Store, seperti sistem informasi internal Rp 65.000.000 dengan estimasi 10 sampai 16 pekan. Untuk produk yang masih banyak berubah, model per waktu kerja (misalnya per sprint dua minggu) sering lebih jujur bagi kedua pihak, karena Anda hanya membayar yang benar-benar dikerjakan.

4. Pastikan kontrak menjawab soal kepemilikan

Ini bagian yang paling sering bermasalah. Tuliskan dengan jelas:

1. Source code menjadi milik Anda setelah pembayaran lunas, dan diserahkan lewat repositori yang Anda kendalikan.
2. Domain, server, akun Play Store, App Store, dan payment gateway didaftarkan atas nama perusahaan Anda.
3. Kredensial dan dokumentasi teknis diserahkan saat proyek selesai.
4. Kerahasiaan data, terutama kalau aplikasi menyimpan data pelanggan.

Kalau vendor keberatan dengan poin-poin ini, tanyakan alasannya. Ada model bisnis yang sah di mana vendor menyewakan platformnya, tapi itu harus disebut terang-terangan, bukan baru ketahuan saat Anda ingin pindah.

5. Tanyakan cara mereka menjaga kualitas

Anda tidak perlu bisa membaca kode untuk menanyakan hal ini:

• Apakah ada lingkungan staging untuk mencoba fitur sebelum dipasang ke aplikasi utama?
• Bagaimana mereka menguji keamanan? Jawaban yang baik menyebut hal konkret seperti pengecekan hak akses, validasi input, dan pengelolaan secret. Gambaran lengkapnya ada di checklist keamanan aplikasi web berdasarkan OWASP Top 10.
• Bagaimana API didokumentasikan, supaya tim lain bisa melanjutkan kalau suatu hari dibutuhkan. Prinsipnya kami tulis di praktik terbaik desain API.
• Siapa yang menjadi kontak harian Anda, dan seberapa cepat respons yang bisa diharapkan?

6. Waspadai tanda bahaya ini

• Harga jauh di bawah yang lain tanpa penjelasan. Biasanya ada yang dikorbankan: pengujian, dokumentasi, atau dukungan setelah rilis.
• Minta pembayaran penuh di depan untuk proyek berbulan-bulan. Pembayaran bertahap per milestone lebih sehat untuk kedua pihak.
• Tidak pernah ada demo sampai mendekati tenggat. Anda berhak melihat progres secara berkala.
• Semua permintaan dijawab "bisa". Software house yang berpengalaman akan berkata "bisa, tapi ini konsekuensinya" atau "sebaiknya jangan dulu".
• Tidak jelas siapa yang mengerjakan. Proyek dijual oleh satu pihak lalu diteruskan ke freelancer tanpa sepengetahuan Anda.

Langkah praktis memilih

Kalau saya di posisi Anda, ini urutannya. Pilih tiga kandidat. Kirim brief yang sama ke ketiganya, satu sampai dua halaman cukup. Bandingkan pertanyaan yang mereka ajukan balik, karena vendor yang bertanya banyak biasanya lebih memahami masalah Anda. Minta satu sesi diskusi teknis singkat. Baru setelah itu bandingkan harga.

Untuk proyek yang besar dan masih kabur bentuknya, mulai dengan sesi konsultasi berbayar sebelum menandatangani proyek penuh. Di kami, konsultasi dua jam bersama senior engineer berharga Rp 1.500.000, bisa daring atau langsung di kantor Anda di Jakarta. Hasilnya bisa Anda bawa ke vendor mana pun. Untuk aplikasi yang sudah berjalan, audit keamanan (Rp 12.500.000) sering menjadi cara paling jujur untuk menilai kualitas kerja vendor sebelumnya.

Kalau yang Anda butuhkan sebenarnya hanya website, kriterianya lebih sederhana. Panduannya ada di jasa pembuatan website: harga, proses, dan cara memilih.

Pertanyaan yang sering diajukan

Apa bedanya software house dan freelancer?

Software house bekerja sebagai tim dengan badan usaha, kontrak, dan biasanya proses pengujian yang lebih lengkap. Freelancer bisa sangat bagus dan lebih hemat untuk proyek kecil, tapi risikonya bergantung pada satu orang.

Apakah software house harus berlokasi di kota yang sama?

Tidak harus. Sebagian besar proyek sekarang berjalan daring dengan demo rutin. Pertemuan tatap muka tetap berguna di awal proyek untuk memahami proses bisnis Anda.

Berapa termin pembayaran yang wajar?

Umumnya uang muka di awal, lalu sisanya dibagi per milestone yang bisa didemokan, dengan pelunasan setelah serah terima. Hindari pembayaran penuh di depan untuk proyek panjang.

Bagaimana kalau saya ingin ganti vendor di tengah jalan?

Kalau source code, akses server, dan dokumentasi sudah atas nama Anda, pindah vendor jauh lebih mudah. Itu sebabnya poin kepemilikan di kontrak sangat penting sejak awal.

Kalau Anda sedang menyusun brief dan ingin pendapat kedua, kirimkan lewat halaman kontak. Daftar layanan KSATRIA bisa Anda lihat untuk tahu apa yang kami kerjakan, dan informasi umum tentang KSATRIA ada di halaman utama.