5 Hal yang Wajib Ada di Kontrak Software House (Sebelum Anda Tanda Tangan)

Polanya hampir selalu sama. Proyek berjalan mulus di awal, semua ramah, demo pertama menjanjikan. Lalu di sekitar 80% perjalanan, momentum melambat. Revisi menumpuk, jadwal mundur, komunikasi makin susah. Dan ketika Anda minta source code untuk berjaga-jaga, jawabannya mengambang — "nanti setelah lunas", padahal "lunas" tidak pernah benar-benar tercapai karena ada saja yang belum selesai.

Cerita ini terlalu umum. Dan hampir selalu, akarnya bukan vendor yang jahat, melainkan kontrak yang tidak mengatur hal-hal penting sejak awal.

Posisi kami soal ini mungkin tidak biasa untuk sebuah software house: kami akan kasih tahu cara melindungi diri Anda dari vendor — termasuk dari kami. Kontrak yang baik melindungi kedua pihak. Vendor yang menolak memperjelas poin-poin di bawah ini justru memberi Anda sinyal paling jujur soal siapa mereka.

Berikut lima hal yang wajib ada — dan satu daftar red flag di akhir.

Hal 1 Kepemilikan Source Code dan IP

Ini yang paling sering disandera, jadi taruh paling depan.

Pertanyaan yang harus dijawab kontrak dengan eksplisit: siapa pemilik source code, dan kapan kepemilikan itu berpindah?

Jawaban yang sehat: source code dan seluruh hak kekayaan intelektual menjadi milik klien setelah pembayaran lunas. Bukan "lisensi untuk memakai", tapi kepemilikan penuh. Termasuk akses ke repository (misalnya GitHub atau GitLab), bukan sekadar file zip yang dikirim di akhir.

Yang harus Anda waspadai:

• Kontrak diam soal kepemilikan. Kalau tidak disebut, asumsikan itu akan jadi sengketa.
• Vendor menahan source code sebagai "jaminan" tanpa batas waktu atau syarat yang jelas.
• Anda hanya dapat hasil build, bukan kode sumbernya — artinya Anda tidak bisa pindah vendor atau melanjutkan sendiri.

Minta klausul yang menyebut: kepemilikan berpindah ke klien saat pelunasan, akses repository diberikan, dan semua kredensial (server, domain, akun pihak ketiga) diserahkan. Ini fondasi yang membuat empat poin berikutnya bermakna.

Hal 2 Milestone dan Termin Pembayaran

Cara Anda membayar menentukan seberapa besar leverage yang Anda pegang kalau ada masalah.

Hindari membayar 50% di muka. Pembayaran besar di awal memindahkan hampir semua risiko ke Anda: begitu uang berpindah, insentif vendor untuk menyelesaikan dengan cepat berkurang, dan kalau proyek macet, Anda sudah kehilangan setengah anggaran tanpa produk yang utuh.

Struktur bertahap yang terikat milestone jauh lebih sehat. Pola yang kami pakai di proposal kami sendiri adalah 30/40/20/10:

Termin	Porsi	Dibayar saat
1	30%	Kontrak ditandatangani, proyek dimulai
2	40%	Milestone pengembangan inti tercapai
3	20%	Selesai pengembangan & masuk pengujian
4	10%	Serah terima final & diterima klien

Kuncinya bukan angka pastinya, tapi prinsipnya: setiap pembayaran terikat pada hasil yang bisa diverifikasi, dan ada porsi terakhir yang baru cair setelah serah terima diterima. Itu menjaga kedua pihak tetap punya kepentingan sampai garis akhir — vendor punya alasan menyelesaikan, dan Anda tidak pernah membayar lebih dulu dari yang sudah Anda terima.

Untuk memahami bagaimana termin ini cocok dengan komponen biaya proyek secara keseluruhan, panduan investasi website bisnis memberi gambaran angka yang lebih utuh.

Hal 3 Scope dan Mekanisme Perubahan

Sebagian besar konflik proyek software bukan soal kualitas, tapi soal "ini termasuk atau tidak".

Kontrak harus punya dua hal: scope yang ditulis cukup detail, dan mekanisme yang jelas untuk perubahan.

Scope yang sehat menyebutkan apa yang dikerjakan dan, sama pentingnya, apa yang tidak. Tanpa itu, setiap "sekalian dong" di tengah jalan jadi sumber gesekan: Anda menganggap itu sudah termasuk, vendor menganggap itu pekerjaan tambahan.

Yang melindungi kedua pihak adalah mekanisme change request tertulis. Setiap perubahan di luar scope awal dicatat: apa yang diminta, dampaknya ke waktu, dan dampaknya ke biaya — lalu disetujui dulu sebelum dikerjakan. Ini bukan birokrasi; ini yang mencegah proyek membengkak diam-diam dan mencegah hubungan rusak karena salah ekspektasi.

Tanda bahaya: vendor yang dengan mudah bilang "iya bisa, gratis kok" untuk setiap permintaan tambahan. Kedengarannya enak di awal, tapi biasanya berarti scope tidak pernah benar-benar terkunci, dan biaya tersembunyi akan muncul di tempat lain — atau kualitas yang dikompromikan.

Hal 4 Garansi dan Masa Support

Setelah serah terima, akan ada bug yang baru muncul di kondisi nyata. Kontrak harus mengatur siapa yang menanggung apa.

Bedakan dua hal dengan tegas:

• Bug. Sesuatu yang tidak berjalan sesuai spesifikasi yang sudah disepakati. Ini tanggung jawab vendor, dan seharusnya diperbaiki gratis selama masa garansi.
• Fitur baru. Penambahan atau perubahan di luar spesifikasi awal. Ini wajar dikenakan biaya, karena memang pekerjaan baru.

Kontrak yang baik menyebut berapa lama masa garansi (misalnya 1-3 bulan setelah serah terima), apa yang masuk garansi, dan bagaimana support setelah masa garansi berakhir — apakah ada paket maintenance, berapa biayanya, dan respons time-nya seperti apa.

Tanpa kejelasan ini, setiap bug pasca-launch berpotensi jadi perdebatan: Anda menganggapnya tanggung jawab vendor, vendor menganggapnya permintaan berbayar. Tentukan aturannya sebelum tanda tangan, saat kedua pihak masih tenang.

Hal 5 Exit Clause dan Serah Terima

Tidak ada yang berharap kerja sama putus di tengah jalan, tapi kontrak yang dewasa tetap mengaturnya. Justru keberadaan exit clause yang adil adalah tanda vendor yang percaya diri.

Yang harus diatur kalau hubungan dihentikan sebelum selesai:

• Serah terima source code dan dokumentasi sejauh yang sudah dikerjakan, dalam kondisi yang bisa dilanjutkan pihak lain.
• Penyerahan kredensial — akses server, domain, akun pihak ketiga, database. Tanpa ini, Anda secara teknis tersandera meski secara hukum berhak.
• Penyelesaian pembayaran atas pekerjaan yang sudah benar-benar selesai, tidak lebih dan tidak kurang.

Inti dari exit clause adalah memastikan Anda tidak pernah berada di posisi di mana satu-satunya pilihan adalah menyerah total. Kalau kerja sama harus berakhir, Anda bisa membawa hasil yang sudah dibayar dan melanjutkannya — sendiri atau dengan vendor lain.

Red Flags di Kontrak Vendor

Sebagai penutup, ini sinyal-sinyal yang layak membuat Anda berhenti dan bertanya lebih dalam sebelum tanda tangan:

1. Kontrak diam soal kepemilikan source code. Hampir selalu jadi masalah belakangan.
2. Minta pembayaran 50% atau lebih di muka. Risiko berpindah hampir seluruhnya ke Anda.
3. Scope ditulis kabur dengan banyak istilah seperti "dan lain-lain" tanpa batas yang jelas.
4. Tidak ada mekanisme change request. Berarti setiap perubahan berpotensi jadi sengketa.
5. Tidak ada masa garansi yang disebut, atau garansi yang ruang lingkupnya tidak jelas.
6. Menolak mencantumkan exit clause atau tersinggung saat Anda memintanya.
7. Tidak mau menyerahkan kredensial sebagai bagian dari serah terima.

Satu red flag belum tentu fatal — bisa jadi hanya kontrak yang belum lengkap dan masih bisa diperbaiki. Tapi vendor yang menolak memperjelas poin-poin ini ketika Anda minta, itu sinyal yang jauh lebih penting daripada harga atau portofolio mereka.

Kalau Anda ingin filter vendor lebih dalam sebelum sampai ke tahap kontrak, 12 pertanyaan untuk memilih software house melengkapi daftar ini. Dan kalau Anda sedang menimbang vendor lokal versus luar negeri, perbandingan jujur software house lokal vs outsourcing membahas mengapa isi kontrak jadi makin krusial saat vendor berada di yurisdiksi lain.

Kesimpulan

Kontrak yang baik bukan tanda saling tidak percaya — justru sebaliknya. Ia membuat ekspektasi kedua pihak eksplisit, sehingga energi bisa difokuskan ke membangun produk, bukan ke memperdebatkan siapa salah saat ada masalah.

Lima hal ini — kepemilikan source code, termin pembayaran bertahap, scope dengan mekanisme perubahan, garansi yang jelas, dan exit clause — adalah perlindungan dasar yang berlaku untuk vendor mana pun, termasuk kami. Sebelum Anda tanda tangan, pastikan kelimanya ada dan Anda paham isinya.

---

Mau dicek dulu poin-poin kontrak sebelum Anda tanda tangan dengan vendor? Diskusi gratis via WhatsApp — kami bantu Anda baca kontrak dengan jujur, bahkan kalau vendornya bukan kami.

WhatsApp: +62 878-9777-9893 · Email: poedi@albatech.id