Owner Nggak Perlu Ngerti Coding, Tapi Wajib Tahu Ini Sebelum Bayar Developer
Owner nggak perlu ngerti coding, tapi ada beberapa hal yang wajib dicek sebelum bayar developer atau software house: siapa yang pegang kode dan akunnya, ada dokumentasi atau nggak, dan apa aja yang termasuk di harga.

Beberapa klien yang datang ke aku itu ceritanya mirip-mirip: mereka udah pernah bayar developer atau software house sebelumnya, sistemnya emang jadi, tapi begitu mau nambah fitur, ganti orang yang pegang, atau sekadar mau tahu datanya ada di mana, ternyata semuanya nggak sesederhana yang dibayangkan.
Kamu nggak perlu ngerti coding buat menghindari itu. Yang perlu cuma tahu apa yang harus ditanyain sebelum bayar, bukan sesudahnya.
Yang paling sering kelewat: siapa yang pegang kodenya
Ini pertanyaan yang jarang ditanya di awal, padahal paling penting: begitu project selesai, kode programnya bakal diserahin ke kamu, atau tetap dipegang developer-nya?
"Diserahin" di sini maksudnya konkret: repository kodenya ada di akun kamu sendiri (atau akun perusahaan kamu), bukan cuma "nanti dikasih lihat kalau perlu". Kalau kodenya tetap di akun pribadi developer, secara praktis kamu nggak benar-benar punya sistem itu, meskipun udah dibayar lunas. Kalau suatu saat developer-nya nggak bisa dihubungi, kamu mulai dari nol lagi.
Pertanyaan simpelnya: "Kodenya nanti ada di akun saya atau akun kamu?"
Domain, hosting, dan akun-akun lain juga harus atas nama kamu
Ini masalah yang mirip tapi sering kelewat justru karena kelihatannya bukan bagian dari "kode". Domain, hosting, API key, sampai akun email buat kirim notifikasi, semuanya perlu didaftarkan atas nama kamu atau perusahaan kamu, bukan atas nama developer-nya.
Praktiknya gampang: kalau developer yang daftarin, minta email dan akses login-nya dipindah ke kamu begitu selesai. Kalau mereka keberatan atau nunda-nunda soal ini, itu sinyal yang perlu diwaspadai.
Aku sendiri selalu pilih platform yang ekosistemnya luas justru karena alasan ini. Di case study website DSM, misalnya, aku pilih WordPress karena dipakai lebih dari 40% website di dunia, jadi kliennya gampang cari orang lain buat merawat websitenya nanti, dan nggak terkunci ke aku doang.
Dokumentasi: bedanya sistem yang bisa dilanjutin orang lain vs kotak hitam
Kode yang udah di tangan kamu pun nggak banyak gunanya kalau nggak ada yang ngerti cara kerjanya. Dokumentasi itu yang bikin sistemnya bisa dilanjutin siapa aja, bukan cuma orang yang bikin.

Dokumentasi minimal yang wajar diminta: cara install ulang atau deploy sistemnya, di mana kredensial dan API key disimpan, dan alur kerja utama sistemnya secara garis besar. Nggak perlu setebal manual buku, tapi harus ada yang bisa dibaca orang lain, bukan cuma comment di kode yang cuma developer aslinya yang paham.
Baca detail harganya: apa yang termasuk, apa yang jadi biaya tambahan
Harga yang ditawarkan biasanya jelas di angka, tapi nggak selalu jelas di cakupannya. Beberapa hal yang sering bikin kaget belakangan:
- Revisi. Berapa kali revisi termasuk di harga, dan setelah itu dihitung per jam atau per paket baru?
- Biaya jalan. Hosting, domain, dan API itu biasanya biaya terpisah yang jalan terus, bukan sekali bayar. Pastikan itu jelas dari awal, bukan kejutan pas tagihan pertama.
- Perubahan scope. Kalau di tengah jalan ada fitur tambahan, gimana cara ngitung biayanya?
Nggak ada jawaban benar atau salah buat pertanyaan-pertanyaan ini, tapi kamu berhak tahu jawabannya sebelum, bukan sesudah, tanda tangan.
Maintenance setelah selesai: siapa yang pegang kalau ada masalah
"Selesai" buat software itu beda arti sama "selesai" buat barang fisik. Ada masa garansi buat perbaikan bug, biasanya beberapa minggu sampai sebulan setelah rilis, dan setelah itu biasanya ada pilihan: lanjut kontrak maintenance, atau jalan sendiri.
Yang penting kamu tahu dari awal, bukan pilihan mana yang lebih baik, tapi kamu punya pilihan sama sekali. Ini balik lagi ke soal kepemilikan kode dan dokumentasi di atas: kalau dua itu udah beres, kamu bebas mau lanjut sama developer yang sama atau pindah ke orang lain.
Cara ngecek portfolio dan referensi yang beneran
Portfolio yang ditunjukkan biasanya udah dipilih yang paling bagus, jadi itu wajar. Yang lebih berguna adalah minta lihat salah satu project yang masih jalan sekarang (bukan cuma screenshot), dan kalau memungkinkan, ngobrol langsung sama kliennya soal gimana prosesnya, bukan cuma hasil akhirnya.
Tanda-tanda yang patut dicurigai
- Nggak mau jelasin hal teknis pakai bahasa yang gampang dimengerti, seolah itu memang harus dirahasiakan.
- Nggak ada kesepakatan tertulis sama sekali, semua cuma janji lisan atau chat.
- Minta dibayar lunas di muka sebelum ada progres apa pun yang bisa dicek.
- Menghindar kalau ditanya soal kepemilikan kode atau dokumentasi seperti di atas.
Satu tanda merah aja mungkin belum tentu masalah. Tapi kalau beberapa tanda ini muncul bareng, itu alasan yang cukup buat berhenti sejenak dan mikir ulang.
Penutup
Kamu nggak perlu jadi developer buat menghindari masalah-masalah di atas. Yang perlu cuma keberanian nanya hal-hal ini di awal, sebelum uang keluar, bukan setelah sistemnya jadi dan kamu baru sadar nggak benar-benar pegang kendali atasnya.
Kalau kamu lagi mau mulai project dan mau tahu pertanyaan apa lagi yang relevan buat kebutuhan spesifik kamu, cerita aja dulu kondisinya, nanti dibantu mikirin dari sudut pandang kamu sebagai yang bayar, bukan yang ngerjain.
Ada proses di tim kamu yang masih manual?
Cerita aja, kita cariin solusinya bareng.
Catatan lainnya

Bisakah AI Belajar Gaya Jualan dari Riwayat Chat WhatsApp?
Bisa, dan biasanya nggak perlu melatih model sendiri. Cara ekspor chat WhatsApp, mengubahnya jadi panduan gaya, prompt siap pakai, serta risiko data pelanggannya.
Baca catatan
Bedanya Gemini dan ChatGPT untuk Kerja Kantor, Mana yang Lebih Cocok?
Gemini dan ChatGPT sama-sama bisa dipakai kerja, tapi kekuatannya beda. Harga paket dalam Rupiah, mana yang cocok untuk tim di Google Workspace, dan kapan ChatGPT lebih pas.
Baca catatan