Checklist Serah Terima Proyek Aplikasi: Hakmu dari Vendor

Saat proyek aplikasi selesai, ada lima kelompok hal yang wajib kamu terima dari vendor: akses dan kepemilikan penuh (source code, hosting, domain, database, akun pihak ketiga), dokumentasi teknis, kejelasan legal dan lisensi, kesepakatan garansi serta penanganan bug, dan yang terakhir, kepastian bahwa tidak ada satu pun aset yang “disandera” vendor. Kalau salah satu dari lima ini tidak kamu pegang, proyekmu belum benar-benar selesai, berapa pun invoice yang sudah lunas.

Kami menulis ini dari posisi yang mungkin terdengar aneh: kami sendiri software house. Artinya kami tahu persis celah mana yang sering dimanfaatkan vendor untuk membuat klien bergantung selamanya. Sebagian besar klien baru sadar ada masalah justru saat mau pindah vendor, lalu menemukan bahwa domain bukan atas nama mereka atau source code tidak pernah diserahkan. Artikel ini membocorkan daftar lengkapnya, item per item, supaya kamu bisa menagih hakmu sebelum terlambat.

1. Akses dan Kepemilikan: Ini yang Paling Sering Ditahan

Ini kelompok paling penting sekaligus paling sering bermasalah. Prinsipnya sederhana. Kamu yang bayar, kamu yang punya. Semua akses harus atas nama kamu atau perusahaanmu, bukan atas nama vendor.

• Source code dalam bentuk repository Git, bukan file zip. Ini penting. File zip hanya potret satu momen. Repository Git menyimpan seluruh riwayat perubahan kode, siapa mengubah apa dan kapan. Developer baru yang meneruskan proyekmu akan sangat terbantu oleh riwayat ini. Minta kamu dijadikan owner di GitHub, GitLab, atau Bitbucket, atau minta repository dipindahkan ke akun organisasimu.
• Akun hosting dan domain atas nama kamu. Domain adalah identitas bisnismu. Kalau terdaftar atas nama vendor, secara administratif itu milik mereka. Cek di registrar siapa pemiliknya. Hosting juga sama. Idealnya kamu yang bikin akun, vendor hanya diberi akses kerja yang bisa dicabut kapan saja.
• Akses database. Data pelanggan, transaksi, dan konten adalah asetmu yang paling berharga. Minta kredensial database plus cara melakukan backup. Tanpa ini, datamu ada di tangan orang lain.
• Akun layanan pihak ketiga. Payment gateway, API pengiriman, layanan email, push notification, Google Maps, dan sejenisnya. Semua akun ini harus dibuat dengan email perusahaanmu. Khusus payment gateway ini krusial karena menyangkut uang yang mengalir ke rekening. Kalau akunnya milik vendor, uangmu lewat jalur mereka.
• Password admin aplikasi. Terdengar sepele, tapi banyak klien tidak pernah pegang akses admin tertinggi di sistemnya sendiri. Minta akun super admin, lalu ganti password-nya setelah serah terima.

Satu tips praktis. Jangan tunggu hari serah terima untuk mengecek semua ini. Cicil dari awal proyek. Akun-akun dibuat atas nama kamu sejak hari pertama, jauh lebih mudah daripada proses migrasi di akhir.

2. Dokumentasi: Bekal untuk Developer Setelahnya

Aplikasi tanpa dokumentasi itu seperti mesin tanpa buku manual. Masih jalan, tapi begitu ada masalah, tidak ada yang tahu harus mulai dari mana. Dokumentasi yang layak kamu minta minimal mencakup tiga hal.

• Cara deploy. Langkah-langkah memasang aplikasi dari nol sampai jalan di server. Termasuk kebutuhan server, versi bahasa pemrograman, dan perintah yang harus dijalankan. Tanpa ini, pindah server bisa jadi proyek tersendiri yang mahal.
• Daftar environment variable. Ini konfigurasi rahasia seperti kunci API, kredensial database, dan setting per server. Biasanya tidak ikut tersimpan di repository demi keamanan. Justru karena itu harus diserahkan terpisah dan tercatat. Aplikasi yang kodenya lengkap tapi environment variable-nya hilang tetap tidak bisa jalan.
• Dokumentasi API, kalau ada. Kalau aplikasimu punya backend yang diakses aplikasi mobile atau sistem lain, minta dokumentasi endpoint-nya. Cukup format sederhana seperti Postman collection atau Swagger. Ini menghemat berminggu-minggu kerja developer berikutnya.

Dokumentasi tidak perlu setebal skripsi. Satu file README yang jujur dan up to date jauh lebih berharga daripada dokumen 50 halaman yang tidak pernah diperbarui.

3. Legal dan Lisensi: Hitam di Atas Putih

Bagian ini sering dilewati karena dianggap formalitas. Padahal di sinilah sengketa biasanya bermula.

• Kepemilikan kode harus tertulis di kontrak. Di banyak yurisdiksi, tanpa klausul penyerahan hak, hak cipta kode secara default bisa tetap di tangan pembuatnya. Jadi jangan berasumsi. Pastikan kontrak menyebut jelas bahwa hasil kerja, termasuk source code, menjadi milik klien setelah pelunasan.
• Lisensi library dan komponen berbayar. Hampir semua aplikasi modern dibangun di atas library pihak ketiga. Sebagian gratis, sebagian berbayar per proyek atau per tahun. Minta daftar komponen berbayar yang dipakai, atas nama siapa lisensinya, dan berapa biaya perpanjangannya. Kamu tidak mau kaget aplikasi berhenti berfungsi karena lisensi template atau plugin kedaluwarsa.
• Perjanjian maintenance yang terpisah dan jelas. Setelah garansi habis, siapa yang merawat sistem? Berapa biayanya, apa saja cakupannya, dan bagaimana cara mengakhirinya? Perjanjian maintenance yang bagus juga menyebut apa yang terjadi kalau kontrak berakhir. Yang penting, maintenance harus jadi pilihan, bukan keterpaksaan karena hanya vendor itu yang pegang akses.

4. Serah Terima Teknis: Garansi, Bug, dan Batas Revisi

Aplikasi yang baru rilis hampir pasti masih punya bug. Itu normal. Yang tidak normal adalah kalau tidak ada kesepakatan soal siapa yang memperbaikinya dan sampai kapan. Sebelum tanda tangan berita acara serah terima, pastikan hal-hal berikut sudah disepakati.

• Masa garansi bug. Di industri ini umumnya 1 sampai 3 bulan setelah go live. Dalam periode ini, error yang berasal dari kode vendor diperbaiki tanpa biaya. Pastikan definisinya jelas: garansi mencakup bug, bukan fitur baru.
• Format pelaporan bug. Sepakati lewat mana bug dilaporkan, entah grup chat, email, atau tools tiket. Sepakati juga informasi apa yang perlu kamu sertakan, misalnya screenshot dan langkah untuk mereproduksi masalah, plus estimasi waktu respons. Tanpa jalur yang jelas, laporan bug gampang hilang dan dua pihak saling menunggu.
• Batas revisi. Bedakan tiga hal ini sejak awal: bug (masuk garansi), revisi minor (biasanya ada jatahnya di kontrak), dan fitur baru (kerjaan baru dengan biaya baru). Perselisihan klien dan vendor paling sering terjadi karena tiga hal ini dicampur aduk. Vendor merasa dimintai kerja gratis, klien merasa ditagih untuk hal yang seharusnya beres.

Minta juga sesi serah terima teknis, semacam walkthrough. Vendor menjelaskan arsitektur sistem ke kamu atau ke tim IT-mu, direkam kalau perlu. Satu jam sesi ini bisa menyelamatkanmu dari kebingungan bertahun-tahun.

5. Tanda Bahaya: Pola Vendor yang Perlu Kamu Waspadai

Sekarang bagian yang jarang dibahas terbuka. Ada beberapa pola yang berulang kali kami dengar dari klien yang datang setelah kecewa dengan vendor sebelumnya. Polanya mirip di mana-mana.

• Source code disandera. Vendor menolak menyerahkan kode dengan alasan “itu aset kami” atau “nanti disalahgunakan”. Padahal kontrak tidak menyebut demikian, atau bahkan tidak ada kontrak sama sekali. Akibatnya klien tidak bisa pindah ke developer lain tanpa membangun ulang dari nol.
• Domain dan hosting atas nama vendor. Saat hubungan baik, ini tidak terasa. Saat hubungan memburuk atau vendor menghilang, domainmu ikut hilang. Ada bisnis yang terpaksa ganti alamat website, ganti email perusahaan, dan kehilangan reputasi yang sudah dibangun bertahun-tahun hanya karena domain tidak pernah atas nama mereka.
• Biaya tebusan di akhir. Modusnya, biaya proyek di awal terlihat murah. Begitu kamu mau memutus hubungan, muncul tagihan “biaya migrasi”, “biaya rilis source code”, atau angka perpanjangan maintenance yang tiba-tiba melonjak. Murah di depan, mahal saat mau keluar.
• Semua serba lisan. Vendor yang menghindari kontrak tertulis dan berita acara serah terima biasanya sedang menjaga ruang abu-abu. Ruang abu-abu itu hampir selalu menguntungkan pihak yang pegang akses, dan itu bukan kamu.

Perlu adil juga. Tidak semua vendor yang menahan sesuatu berarti nakal. Kadang pembayaran memang belum lunas, dan menahan serah terima sampai pelunasan itu wajar. Yang jadi masalah adalah ketika kewajibanmu sudah beres tapi hakmu tidak kunjung diserahkan.

Pertanyaan yang Sebaiknya Kamu Ajukan Sebelum Kontrak

Semua masalah di atas jauh lebih murah dicegah daripada diperbaiki. Sebelum tanda tangan kontrak pembuatan sistem atau aplikasi, ajukan pertanyaan-pertanyaan ini ke calon vendormu.

• Setelah lunas, apakah source code jadi milik saya sepenuhnya, dan diserahkan dalam bentuk repository Git?
• Domain, hosting, dan semua akun layanan pihak ketiga akan didaftarkan atas nama siapa?
• Kalau suatu saat saya pindah vendor, apa saja yang saya bawa dan adakah biaya tambahan untuk itu?
• Berapa lama masa garansi bug, dan apa saja cakupannya?
• Apa saja dokumentasi yang saya terima di akhir proyek?
• Adakah komponen berbayar di dalam sistem, dan atas nama siapa lisensinya?

Perhatikan bukan hanya jawabannya, tapi cara menjawabnya. Vendor yang sehat akan menjawab lugas karena pertanyaan ini memang standar. Vendor yang berbelit atau tersinggung saat ditanya soal kepemilikan, itu sinyal yang layak kamu catat.

Posisi Kami Soal Ini

Di Arrazy Inovasi, prinsipnya sederhana. Kode yang kamu bayar adalah milikmu. Repository, akses hosting, database, dan dokumentasi kami serahkan saat serah terima, dan klien bebas melanjutkan dengan tim mana pun. Kami lebih memilih klien bertahan karena puas dengan hasil kerja, bukan karena tidak punya pilihan untuk pergi.

Kalau kamu sedang menghadapi serah terima proyek dan ragu apa saja yang berhak kamu minta, atau sedang menimbang pindah vendor, hubungi kami. Ceritakan situasimu, dan kami bantu petakan langkahnya. Konsultasi awal tidak dipungut biaya, dan tidak ada kewajiban lanjut.