Cara Memilih Software House untuk Proyek Perusahaan: 10 Hal yang Perlu Dicek Sebelum Tanda Tangan Kontrak

Cara memilih software house yang tepat adalah menilai bukti, bukan janji: portofolio yang relevan, tim yang benar-benar mengerjakan, proses kerja yang terdokumentasi, pengujian, keamanan, kontrak yang jelas, dan dukungan setelah aplikasi berjalan. Semua itu sebaiknya dicek sebelum tanda tangan kontrak, karena begitu proyek berjalan, mengganti vendor hampir selalu lebih mahal daripada memilih dengan teliti sejak awal.

Panduan ini kami tulis dari sisi dalam. WIT adalah software house di Bandung yang berdiri sejak 2010, dengan gateway di Jakarta dan Surabaya. Sejak itu, kami sering duduk bersama calon klien yang sedang membandingkan beberapa vendor, dan checklist di bawah lahir dari percakapan seperti itu. Checklist ini berlaku untuk vendor mana pun, termasuk kami.

Software House, Freelancer, atau Tim Internal: Mana yang Cocok?

Sebelum membandingkan vendor, pastikan dulu bahwa software house memang jalur yang tepat. Ada tiga pilihan umum, dan masing-masing cocok untuk situasi yang berbeda. Kalau yang dibutuhkan hanya tambahan tenaga untuk tim yang sudah ada, pertimbangkan juga IT outsourcing.

Dalam praktiknya, banyak perusahaan menggabungkan ketiganya. Pola yang cukup umum: perusahaan software house membangun versi pertama, sementara Anda menunjuk satu atau dua orang internal sebagai product owner yang memegang keputusan. Setelah sistem stabil, pengembangan bisa dilanjutkan vendor yang sama, diambil alih tim internal, atau dikerjakan bersama dengan menempatkan tenaga IT dari vendor di tim Anda, yang biasa disebut IT outsourcing.

Kalau kebutuhan Anda masih samar, jangan langsung memesan aplikasi lengkap atau merekrut tim besar. Mulailah dari discovery atau MVP kecil untuk menguji ide.

Cara Memilih Software House: 10 Hal yang Perlu Dicek

Tidak ada satu software house terbaik di Indonesia untuk semua proyek. Yang ada adalah vendor yang paling cocok dengan kebutuhan, anggaran, dan cara kerja perusahaan Anda. Gunakan sepuluh poin berikut untuk membandingkan dua atau tiga kandidat secara adil: ajukan pertanyaan yang sama ke semuanya, lalu minta jawabannya secara tertulis.

1. Portofolio di industri serupa

Portofolio yang cantik belum tentu relevan. Cari proyek yang mirip dari sisi masalah, bukan hanya tampilan. Aplikasi rumah sakit harus menjaga data pasien yang sensitif dan menangani alur antarunit yang rumit, sementara sistem pabrik berurusan dengan shift, mesin, dan data produksi. Vendor yang pernah menghadapi masalah serupa biasanya lebih cepat memahami kebutuhan Anda dan lebih jarang salah asumsi.

Minta vendor menunjukkan aplikasi yang sudah berjalan, bukan hanya gambar layar. Tanyakan juga apa persisnya peran mereka: membangun dari nol, melanjutkan pekerjaan vendor lain, atau hanya mengerjakan desain. Kalau memungkinkan, minta izin berbicara langsung dengan salah satu klien mereka.

2. Proses discovery dan dokumen kebutuhan

Discovery adalah tahap memahami bisnis Anda dan menerjemahkannya menjadi kebutuhan sistem sebelum coding dimulai. Vendor yang serius akan banyak bertanya: siapa penggunanya, bagaimana alur kerja saat ini, data apa yang sudah ada, dan sistem apa saja yang harus terhubung. Dari pengalaman kami, proyek yang molor jarang disebabkan oleh teknologi yang rumit. Penyebabnya lebih sering kebutuhan yang tidak pernah ditulis dengan jelas.

Hasil discovery yang baik berbentuk dokumen, misalnya dokumen kebutuhan (BRD atau SRS), alur pengguna, wireframe atau prototipe, gambaran arsitektur, dan prioritas fitur untuk rilis pertama. Sebagian vendor menagih discovery sebagai tahap terpisah, dan itu wajar. Selama kepemilikannya jelas, dokumen ini tetap berguna bagi Anda, bahkan kalau akhirnya vendor lain yang membangun aplikasinya.

3. Tim yang benar-benar mengerjakan

Orang yang hadir saat presentasi belum tentu orang yang menulis kode Anda. Minta susunan tim sejak awal: project manager, business analyst, UI/UX designer, developer (backend, frontend, atau mobile), QA, dan DevOps bila diperlukan. Tanyakan mana yang karyawan tetap, mana yang freelance, dan bagian apa yang disubkontrakkan.

Minta juga bertemu project manager atau tech lead yang akan memegang proyek Anda. Satu pertanyaan sederhana sering membuka banyak hal: kalau salah satu anggota tim keluar di tengah proyek, bagaimana penggantinya disiapkan, dan siapa yang menanggung waktu transisinya?

4. Metode kerja dan laporan progres

Banyak software house memakai pendekatan agile. Pekerjaan dibagi ke dalam sprint pendek, biasanya satu sampai dua minggu, dan setiap sprint ditutup dengan demo. Ada juga proyek yang lebih cocok dengan pendekatan waterfall, misalnya ketika ruang lingkupnya sudah sangat pasti. Nama metodenya tidak terlalu penting. Yang penting, Anda bisa melihat aplikasi yang benar-benar berjalan secara berkala. Angka persentase kemajuan di laporan saja tidak cukup.

Tanyakan juga format laporannya. Laporan yang berguna memuat pekerjaan yang sudah selesai, rencana berikutnya, kendala, keputusan yang perlu Anda ambil, dan risiko yang mulai terlihat.

5. Testing dan QA

Bug yang ditemukan pengguna setelah aplikasi tayang jauh lebih mahal daripada bug yang ditemukan tim QA sebelum rilis. Tanyakan siapa yang menguji: apakah ada tester khusus, atau developer menguji kodenya sendiri? Jenis pengujian yang umum antara lain uji fungsional, uji regresi (memastikan fitur lama tidak rusak oleh fitur baru), uji integrasi, uji beban, dan uji keamanan.

Pastikan ada lingkungan staging yang terpisah dari production, sehingga Anda bisa mencoba fitur baru tanpa mengganggu data asli. Sepakati juga cara UAT (user acceptance test) dijalankan: siapa dari tim Anda yang menguji, berdasarkan skenario apa, dan bagaimana bug dikelompokkan menurut tingkat keparahannya.

6. Keamanan dan kepemilikan source code

Dari sisi keamanan, tanyakan praktik dasarnya. Bagaimana password dan data sensitif disimpan? Siapa saja yang punya akses ke server dan database production? Apakah ada backup rutin, dan apakah aplikasi diuji terhadap celah umum seperti yang dirangkum dalam OWASP Top 10? Kalau aplikasi mengolah data pribadi pelanggan atau karyawan, vendor juga perlu memahami kewajiban dalam UU Pelindungan Data Pribadi.

Soal source code, pastikan sejak hari pertama kode disimpan di repositori yang bisa Anda akses, idealnya atas nama perusahaan Anda. Tanyakan apa saja yang diserahkan di akhir proyek: source code, dokumentasi teknis, skema database, konfigurasi server, serta akses ke akun domain, hosting, dan cloud. Bedakan juga kepemilikan penuh dengan lisensi pakai, terutama untuk modul yang sudah dimiliki vendor sebelumnya.

7. Kontrak: ruang lingkup, perubahan, dan pembayaran per milestone

Kontrak yang baik melindungi kedua pihak. Ada tiga bagian yang sering menjadi sumber perselisihan:

• Ruang lingkup. Lampirkan dokumen kebutuhan sebagai bagian dari kontrak, lalu tulis juga apa yang tidak termasuk. Kalimat seperti “aplikasi manajemen lengkap” terlalu kabur untuk diuji, apalagi untuk ditagih.
• Perubahan. Sepakati prosedur change request: perubahan diajukan secara tertulis, vendor menghitung dampaknya ke biaya dan jadwal, lalu pekerjaan dimulai setelah Anda setuju.
• Pembayaran per milestone. Kaitkan pembayaran dengan hasil yang bisa diuji dan diterima, misalnya prototipe disetujui, modul tertentu lulus UAT, atau aplikasi tayang, bukan semata dengan tanggal di kalender.

Periksa juga klausul masa garansi, kerahasiaan, hak kekayaan intelektual, dan penghentian kerja sama, termasuk cara menyerahkan pekerjaan yang sudah selesai.

8. Dukungan setelah tayang

Aplikasi yang sudah tayang tetap butuh perawatan: perbaikan bug, pembaruan keamanan, penyesuaian dengan versi Android dan iOS terbaru, pemantauan server, dan backup. Bedakan masa garansi, yang biasanya hanya menanggung bug dari pekerjaan awal, dengan kontrak maintenance yang mencakup perawatan rutin dan perubahan kecil.

Minta vendor menjelaskan SLA-nya: seberapa cepat mereka merespons gangguan menurut tingkat keparahannya, dan siapa yang bisa dihubungi kalau sistem bermasalah di luar jam kerja. Laporan bulanan juga penting, idealnya berisi jam kerja yang terpakai, pekerjaan yang dilakukan, dan rencana bulan berikutnya, sehingga Anda bisa menilai apakah biaya maintenance sepadan.

9. Kemampuan integrasi

Aplikasi perusahaan jarang berdiri sendiri. Biasanya ada data yang harus dipertukarkan dengan ERP, aplikasi akuntansi, payment gateway, sistem gudang, layanan pengiriman, atau marketplace. Di bagian inilah proyek sering tersendat, karena vendor harus menyesuaikan diri dengan sistem pihak lain yang tidak bisa mereka ubah.

Tanyakan integrasi apa saja yang pernah mereka kerjakan dan bagaimana mereka menangani kegagalan: apakah ada mekanisme coba ulang, catatan (log) untuk setiap pertukaran data, dan peringatan otomatis saat koneksi terputus. Kalau ada sistem lama, tanyakan pula rencana migrasi datanya. Data lama sering jauh lebih berantakan daripada yang diperkirakan.

10. Lokasi dan cara berkoordinasi

Coding bisa dikerjakan dari mana saja, tetapi koordinasi tetap butuh ritme. Sepakati satu PIC di masing-masing pihak, kanal komunikasi resmi, jadwal rapat rutin, batas waktu menjawab pertanyaan, dan jalur eskalasi kalau ada masalah. Tanyakan juga momen mana saja yang akan dihadiri tim vendor secara langsung, karena di situlah jarak mulai berpengaruh.

Red Flag yang Perlu Diwaspadai dari Calon Vendor

Beberapa tanda sebaiknya membuat Anda berhenti sejenak, semenarik apa pun penawarannya.

• Harga jauh di bawah pasar. Kalau satu penawaran jauh lebih murah daripada yang lain untuk ruang lingkup yang sama, tanyakan bagian mana yang tidak dihitung. Biasanya ruang lingkupnya dipersempit, timnya diisi tenaga yang belum berpengalaman, atau pengujiannya dipangkas. Selisihnya muncul belakangan sebagai change request, bug, atau jadwal yang molor. Minta rincian estimasi per modul dan per peran supaya perbandingannya apple to apple.
• Tidak ada dokumen. Tidak ada proposal rinci, dokumen kebutuhan, notulen rapat, atau kontrak yang jelas. Tanpa dokumen, setiap beda pemahaman akan berakhir menjadi adu ingatan.
• Menjanjikan fitur sebelum discovery. Vendor yang langsung berkata “semua bisa” dan memberi harga pasti setelah satu pertemuan singkat sebenarnya belum tahu apa yang mereka janjikan.
• Source code tidak diserahkan. Kalau vendor menolak menyerahkan source code atau akses repositori, Anda akan terus bergantung pada mereka untuk setiap perubahan, sekecil apa pun. Kondisi ini dikenal sebagai vendor lock-in, dan keluar darinya hampir selalu mahal.

Pertanyaan untuk Pertemuan Pertama dengan Calon Vendor

Pertemuan pertama adalah kesempatan menilai vendor sebelum ada komitmen apa pun. Bawa daftar berikut dan ajukan apa adanya kepada setiap kandidat. Perhatikan juga apakah vendor balik bertanya tentang bisnis Anda. Vendor yang tidak bertanya apa pun biasanya belum benar-benar memahami masalahnya.

1. Proyek mana di portofolio Anda yang paling mirip dengan kebutuhan kami, dan apa peran tim Anda di sana?
2. Bolehkah kami berbicara dengan salah satu klien Anda?
3. Seperti apa tahap discovery, dan dokumen apa yang kami terima di akhir tahap itu?
4. Siapa saja yang akan mengerjakan proyek ini, dan apakah ada bagian yang disubkontrakkan?
5. Seberapa sering kami bisa melihat demo aplikasi yang sudah berjalan?
6. Bagaimana proses pengujian sebelum sebuah fitur diserahkan kepada kami?
7. Di mana source code disimpan selama proyek, dan apa saja yang diserahkan di akhir?
8. Bagaimana prosedurnya kalau kami ingin mengubah atau menambah fitur di tengah jalan?
9. Apa yang ditanggung masa garansi, dan seperti apa pilihan dukungan setelahnya?
10. Siapa PIC kami, dan ke mana kami melapor kalau ada masalah yang tak kunjung selesai?

Catat jawaban setiap vendor dalam satu tabel, supaya perbedaannya terlihat jelas saat diletakkan berdampingan.

Apakah Lokasi Vendor Berpengaruh? Bandung, Jakarta, dan Surabaya

Untuk pekerjaan coding sehari-hari, lokasi tidak terlalu menentukan. Rapat daring, repositori bersama, dan papan tugas proyek membuat tim di kota yang berbeda tetap bisa bekerja dengan rapi. Pengaruh lokasi baru terasa pada momen yang butuh tatap muka: workshop discovery, UAT bersama pengguna, pelatihan, go-live, dan pekerjaan yang menyentuh perangkat fisik seperti jaringan atau IoT.

Setiap kota punya kelebihan sendiri:

• Bandung dikenal dengan banyak kampus teknik dan komunitas teknologi yang aktif. Bagi perusahaan di Jakarta, bekerja dengan software house Bandung tetap praktis karena jaraknya dekat, apalagi sejak ada kereta cepat.
• Jakarta adalah tempat banyak kantor pusat dan pengambil keputusan berada. Software house Jakarta, atau vendor yang punya tim di sana, memudahkan rapat mendadak dengan manajemen.
• Surabaya adalah pusat bisnis Jawa Timur sekaligus pintu menuju kawasan timur Indonesia, dengan banyak industri manufaktur, perdagangan, dan logistik. Software house Surabaya memberi akses yang lebih dekat ke pabrik, gudang, dan kantor di wilayah itu.

Tetap saja, kemampuan tim lebih penting daripada jarak, asalkan cara berkoordinasinya jelas dan timnya siap hadir di momen-momen penting tadi.

WIT sendiri memakai pola satu Home Base dan dua gateway. Home Base kami ada di Bandung, tempat WIT berdiri pada 2010, sementara gateway Jakarta dan gateway Surabaya menghadirkan WIT sebagai software house dan IT consultant di kedua kota itu. Layanan kami mencakup konsultasi, MVP development, software development, project management, sampai software maintenance. Kalau Anda ingin menguji kami dengan checklist di atas, silakan mulai dari portofolio WIT.

Pertanyaan yang Sering Diajukan

Berapa lama proyek software house biasanya berjalan?

Tergantung ruang lingkup, jumlah integrasi, dan kecepatan keputusan di sisi klien. Website company profile bisa selesai dalam hitungan minggu, sementara aplikasi web atau mobile dengan beberapa integrasi umumnya butuh beberapa bulan. Sistem yang menyentuh banyak divisi sebaiknya dipecah menjadi beberapa fase, supaya versi pertama bisa segera dipakai dan pengembangan berikutnya berjalan berdasarkan masukan pengguna.

Apakah source code menjadi milik klien?

Tergantung kontraknya. UU Hak Cipta pada dasarnya menempatkan pihak yang membuat ciptaan sebagai pemegang hak cipta atas karya yang dibuat berdasarkan pesanan, kecuali diperjanjikan lain. Karena itu, pengalihan hak atas source code perlu ditulis tegas di kontrak, termasuk apa saja yang diserahkan dan kapan. Perhatikan juga komponen yang memang tidak bisa dialihkan, seperti library open source dengan lisensinya sendiri atau platform milik vendor yang hanya dilisensikan. Untuk urusan ini, libatkan penasihat hukum Anda.

Lebih baik vendor lokal atau luar negeri?

Untuk banyak aplikasi bisnis yang dipakai di Indonesia, vendor lokal lebih praktis. Zona waktu dan bahasanya sama, mereka lebih terbiasa dengan integrasi lokal seperti virtual account, e-wallet, dan QRIS, serta lebih paham aturan seperti UU Pelindungan Data Pribadi. Kontrak, pembayaran, dan penyelesaian sengketa juga lebih sederhana karena tunduk pada hukum yang sama. Vendor luar negeri masuk akal untuk teknologi yang sangat khusus, selama Anda siap dengan perbedaan jam kerja dan biaya koordinasinya.

Bagaimana kalau kebutuhan berubah di tengah proyek?

Itu wajar. Kebutuhan sering baru terasa setelah pengguna mencoba versi awal, misalnya tim gudang tiba-tiba butuh fitur scan barcode yang tidak ada di rencana. Yang penting, perubahan masuk lewat prosedur change request tertulis, sehingga dampaknya ke biaya dan jadwal disepakati sebelum dikerjakan. Dengan pendekatan agile, perubahan kecil bisa masuk ke sprint berikutnya dengan menggeser prioritas fitur lain. Perubahan besar sebaiknya dijadwalkan sebagai fase baru supaya tidak mengganggu target rilis pertama.

Sedang menimbang beberapa software house untuk proyek perusahaan Anda? Jadwalkan diskusi dengan tim WIT di Bandung, Jakarta, atau Surabaya, lalu nilai jawaban kami dengan checklist yang sama seperti vendor lain. Kenali dulu WIT sebagai software house di Bandung, atau langsung hubungi kami untuk mengatur jadwal.