Skema Pembayaran Proyek Aplikasi: DP, Termin, dan Siapa Sebenarnya Pemilik Kode

Hampir di setiap pembicaraan awal proyek aplikasi, dua topik selalu muncul sebelum kita bahas fitur: berapa DP yang harus dibayar, dan apakah source code nantinya jadi milik klien. Kedua topik ini terdengar administratif, padahal justru di situlah sengketa paling sering lahir — bukan karena salah satu pihak berniat jahat, melainkan karena ekspektasi tidak pernah ditulis dengan jelas sejak awal. Di artikel ini saya rangkum pengalaman saya menangani proyek dari sisi vendor: skema pembayaran yang umum dipakai, berapa DP proyek software yang masuk akal, dan persoalan kepemilikan kode yang sering dibiarkan mengambang.

Kenapa pembayaran dan kode sering jadi sumber sengketa

Menurut pengalaman saya, sengketa antara klien dan vendor aplikasi hampir selalu berakar pada dua ketakutan yang sama. Klien takut membayar banyak di depan lalu tidak menerima apa yang dijanjikan — wajar, karena kode aplikasi tidak bisa dilihat dan disentuh seperti barang fisik. Vendor, di sisi lain, takut bekerja dulu tanpa jaminan akan dibayar. Kalau kedua ketakutan ini tidak diakui dan diatur sejak awal, keduanya akan saling menuduh di tengah proyek.

Sengketa klasiknya seperti ini: klien merasa sudah membayar separuh sehingga berhak mendapatkan semuanya, sementara vendor merasa pekerjaan yang sudah berjalan belum terbayar layak. Padahal semua ini bisa dicegah dengan satu hal sederhana: kontrak pengembangan aplikasi yang menuliskan skema pembayaran dan kepemilikan kode secara eksplisit, bukan hanya scope dan timeline.

Skema pembayaran yang umum: DP, termin per milestone, pelunasan

Skema yang paling umum saya pakai — dan paling sering saya temui — terdiri dari tiga bagian:

• DP (uang muka) saat kontrak ditandatangani, untuk menutup pekerjaan awal: analisis kebutuhan, desain UI, dan setup teknis.
• Termin per milestone, yaitu pembayaran bertahap yang dipicu oleh selesainya bagian tertentu dari proyek — misalnya setelah desain disetujui, setelah modul inti bisa diuji, atau setelah versi beta siap.
• Pelunasan saat serah terima, setelah aplikasi dirilis dan kelengkapan handover diserahkan.

Struktur ini adil karena melindungi dua pihak sekaligus. DP memberi vendor kepastian untuk mulai bekerja; termin memberi klien kendali karena Anda tidak membayar penuh untuk sesuatu yang belum terlihat hasilnya. Yang saya hindari adalah dua ekstrem: vendor yang meminta pembayaran penuh di depan, atau klien yang menolak DP sama sekali dan ingin semua dibayar setelah aplikasi jadi. Dua-duanya tanda skema yang tidak sehat.

Berapa DP yang wajar, dan kapan termin dikunci ke hasil

Pertanyaan "berapa DP yang wajar" tidak punya jawaban tunggal, tapi ada pola yang masuk akal. Untuk aplikasi skala kecil hingga menengah, DP di rentang 30–50 persen cukup lazim karena pekerjaan awal — analisis dan desain — menyerap usaha yang tidak kecil. Proyek yang lebih besar biasanya justru proporsi DP-nya lebih kecil, dengan termin yang lebih banyak dan lebih terperinci.

Yang jauh lebih penting dari angkanya adalah ikatan termin ke hasil yang jelas. Hindari termin yang didefinisikan berdasarkan waktu semata, misalnya "termin kedua dibayar di bulan kedua". Ganti dengan hasil yang bisa diverifikasi: "termin kedua dibayar setelah modul pendaftaran dan pembayaran bisa diuji di lingkungan staging". Dengan begitu, kalau terjadi perbedaan pendapat, acuannya adalah hasil kerja — bukan interpretasi kalender. Prinsip ini juga membuat termin pembayaran vendor aplikasi terasa lebih adil bagi kedua pihak.

Aturan praktis yang saya pegang: setiap pembayaran harus punya pasangan berupa hasil yang bisa Anda lihat, jalankan, dan uji sendiri — bukan sekadar janji di dokumen presentasi.

Kepemilikan kode: diserahkan penuh vs menyewa sistem langganan

Ini bagian yang paling sering memicu kesalahpahaman, karena ada dua model bisnis yang sama-sama sah — dan Anda perlu tahu sejak awal sedang membeli yang mana.

Model pertama adalah proyek kustom dengan serah terima penuh. Anda membayar pengembangan, dan di akhir proyek source code, dokumentasi, serta hak atas hasil kerja berpindah ke Anda. Model ini cocok kalau aplikasi adalah aset inti bisnis dan Anda ingin bebas memindahkan vendor atau merekrut pengembang internal di masa depan.

Model kedua adalah sistem langganan. Vendor membangun dan mengoperasikan sistem, Anda membayar bulanan atau tahunan, dan kode tetap milik vendor. Model ini sah dan sering lebih ringan di awal, tapi konsekuensinya jelas: kalau langganan berhenti, akses ke sistem bisa ikut berhenti.

Dua-duanya tidak ada yang salah. Yang berbahaya adalah ketidakjelasan. Tanyakan tiga hal sebelum tanda tangan: apakah saya membeli kode atau menyewa sistem; kalau membeli, apa saja yang diserahkan saat handover; kalau menyewa, bagaimana nasib data saya setelah berhenti berlangganan.

Checklist sebelum tanda tangan — dan bagaimana saya bekerja

Sebelum menandatangani kontrak pengembangan aplikasi, periksa lima hal berikut:

1. Kontrak tertulis yang memuat scope kerja, timeline, skema pembayaran, dan klausul kepemilikan kode secara eksplisit.
2. Akses ke repository source code — idealnya Anda bisa melihat progres kode sejak awal, minimal saat handover.
3. Dokumentasi teknis dan panduan admin, bukan hanya aplikasi jadinya.
4. Akun-akun kritis atas nama Anda: domain, server atau hosting, akun developer App Store dan Play Store, serta layanan pihak ketiga yang dipakai aplikasi.
5. Kesepakatan pasca-serah terima: siapa yang merawat, berapa biaya maintenance, dan apa yang terjadi kalau kerja sama berakhir.

Poin keempat sering diremehkan padahal paling krusial — kalau domain dan server terdaftar atas nama vendor, secara praktik Anda hanya menyewa aset sendiri.

Adapun cara saya bekerja: skema pembayaran dijelaskan sejak penawaran, setiap termin diikat ke milestone yang bisa diuji, dan source code beserta dokumentasinya diserahkan tanpa drama saat proyek selesai. Alur lengkapnya saya tulis terbuka di halaman proses kerja saya, dan kalau ada hal yang belum terjawab, biasanya sudah dibahas di daftar pertanyaan yang sering diajukan.

Pada akhirnya, skema pembayaran yang sehat adalah yang membuat kedua pihak sama-sama berani memulai, dan kepemilikan kode yang jelas adalah yang membuat Anda tidak bergantung selamanya pada satu vendor. Kalau Anda sedang merencanakan aplikasi dan ingin membahas skema pembayaran atau kepemilikan kode yang masuk akal untuk kasus Anda, ceritakan kebutuhannya lewat halaman kontak — kita bedah dulu sebelum ada angka atau kontrak yang ditandatangani.