Source Code Aplikasi Itu Milik Siapa: Klien atau Vendor?

Arrazy Inovasi — Mon, 12 Oct 2026 22:25:02 +0000

Pertanyaan ini hampir selalu muncul di akhir proyek, padahal jawabannya ditentukan di awal. Source code aplikasi itu milik siapa? Jawaban jujurnya: tergantung apa yang tertulis di kontrak. Bukan tergantung siapa yang membayar, bukan juga siapa yang mengetik kodenya. Kalau kontrak Anda mengatur kepemilikan kode dengan jelas, urusan selesai. Kalau kontraknya diam, posisinya abu-abu, dan pengalaman kami bilang posisi abu-abu ini hampir selalu merugikan klien. Alasannya sederhana: kodenya secara fisik ada di tangan vendor.

Maka aturan mainnya satu saja. Tulis soal kepemilikan source code di kontrak sebelum Anda membayar, bukan setelah aplikasi jadi. Artikel ini membahas tiga model kepemilikan yang umum dipakai, kenapa vendor kadang menahan kode, dan klausul apa saja yang perlu Anda minta. Kami menulis dari sisi orang dalam sebagai software house, jadi anggap ini pengalaman lapangan, bukan nasihat hukum.

Kenapa jawabannya selalu kembali ke kontrak

Banyak klien mengira logikanya seperti membeli barang. Saya bayar, berarti saya pemilik. Sayangnya software tidak bekerja seperti itu. Secara umum, hak cipta atas sebuah karya melekat pada pihak yang membuatnya, kecuali ada perjanjian yang mengalihkannya. Membayar biaya proyek tidak otomatis memindahkan kepemilikan kode ke tangan Anda.

Di sinilah masalahnya. Sebagian besar kontrak pembuatan aplikasi yang kami lihat hanya mengatur lingkup kerja, harga, dan jadwal. Soal siapa pemilik kode setelah proyek selesai sering tidak disebut sama sekali. Selama hubungan baik, tidak ada yang mempersoalkan. Begitu ada perselisihan atau klien ingin pindah vendor, barulah semua pihak membuka kontrak dan menemukan kontraknya kosong di bagian paling penting.

Kabar baiknya, ini mudah dicegah. Satu pasal yang jelas soal kepemilikan kode menyelesaikan sebagian besar potensi sengketa sebelum sempat terjadi.

Tiga model kepemilikan yang umum dipakai

Tidak ada satu model yang benar untuk semua proyek. Ketiganya sah, selama disepakati terbuka sejak awal. Yang salah adalah tidak membahasnya sama sekali.

1. Full transfer ke klien

Seluruh kode custom yang dibuat untuk proyek Anda menjadi milik Anda setelah pembayaran lunas. Anda bebas menyimpan, memodifikasi, atau menyerahkannya ke tim lain di kemudian hari. Ini model yang paling aman untuk klien, terutama kalau aplikasi itu bagian penting dari operasional bisnis Anda.

Konsekuensinya, harga biasanya lebih tinggi. Vendor tidak bisa memakai ulang kode itu untuk klien lain, jadi seluruh biaya pengembangan dibebankan ke satu proyek. Vendor yang berpengalaman juga biasanya minta pengecualian untuk komponen atau library internal mereka, yaitu potongan kode yang sudah mereka pakai lintas proyek sejak sebelum Anda datang. Itu permintaan yang wajar, selama daftarnya jelas.

2. Lisensi pakai

Kode tetap milik vendor. Anda mendapat hak memakai aplikasinya, biasanya selamanya, tapi tidak boleh menjual ulang atau menyerahkan kodenya ke pihak lain. Model ini wajar untuk produk semi jadi, misalnya sistem yang sudah dipakai banyak klien lalu disesuaikan sedikit untuk kebutuhan Anda. Harganya lebih murah karena biaya pengembangan dibagi ke banyak pemakai.

Kelemahannya jelas: Anda terikat ke vendor itu. Kalau suatu hari ingin pindah, Anda tidak bisa membawa kodenya. Untuk aplikasi pendukung yang mudah diganti, ini bisa diterima. Untuk sistem inti bisnis, pikirkan dua kali.

3. Campuran dengan komponen open source

Ini kenyataan di lapangan yang jarang dijelaskan ke klien. Hampir semua aplikasi modern dibangun di atas library open source, mulai dari framework sampai komponen kecil. Tidak ada vendor yang menulis semuanya dari nol, dan itu bukan masalah. Library open source punya lisensinya sendiri dan memang tidak bisa dialihkan ke siapa pun.

Jadi ketika kontrak menyebut full transfer, yang sebenarnya dialihkan adalah kode custom yang ditulis khusus untuk proyek Anda. Komponen open source ikut terbawa dengan lisensi aslinya. Vendor yang jujur akan menjelaskan ini di depan, bukan memakainya sebagai celah untuk mengaburkan apa yang Anda terima.

Kenapa vendor kadang menahan source code

Supaya adil, tidak semua vendor yang menahan kode sedang berniat buruk. Ada beberapa alasan yang bisa dipahami.

Takut kodenya disalin lalu dipakai kompetitor atau dijual ulang tanpa izin.
Kode itu memang aset bisnis mereka, misalnya produk SaaS yang disewakan ke banyak klien.
Ada library internal yang menjadi pembeda mereka di pasar dan dipakai lintas proyek.

Tapi ada juga alasan yang buruk: menahan kode supaya klien tidak bisa pindah ke mana-mana. Vendor jenis ini tahu bahwa selama kode di tangannya, klien terpaksa terus memakai jasanya berapa pun harganya.

Cara membedakannya tidak sulit. Vendor dengan alasan wajar akan membahas kepemilikan kode sejak awal, menawarkan opsi, dan bersedia menuliskannya di kontrak. Batasannya jelas: bagian ini milik Anda, bagian itu milik kami, dan ini alasannya. Sebaliknya, penyanderaan hampir selalu punya pola yang sama. Topik ini tidak pernah dibahas di awal, kontraknya diam, lalu syarat dan biaya baru muncul tepat ketika Anda ingin pindah. Kalau sebuah alasan baru terdengar saat Anda mau keluar, itu bukan alasan. Itu alat tawar.

Yang harus tertulis di kontrak

Anda tidak perlu kontrak setebal buku. Beberapa poin ini saja sudah menutup sebagian besar risiko.

Siapa pemilik kode custom setelah lunas. Sebut jelas: seluruh kode yang ditulis khusus untuk proyek ini beralih ke klien setelah pembayaran penuh. Kalau ada pengecualian untuk library internal vendor, minta daftarnya ditulis.
Akses repository. Minimal klien punya akses read ke repository selama proyek berjalan, atau menerima salinan berkala. Jangan menunggu serah terima akhir untuk pertama kali melihat kode Anda sendiri.
Komponen berlisensi pihak ketiga. Kalau aplikasi memakai layanan atau library berbayar, tulis siapa yang menanggung biaya perpanjangannya dan atas nama siapa akunnya terdaftar.
Skenario vendor tutup. Apa yang terjadi pada kode kalau vendor berhenti beroperasi. Untuk proyek besar, ada mekanisme bernama source code escrow, yaitu salinan kode dititipkan ke pihak ketiga netral dan diserahkan ke klien pada kondisi tertentu. Untuk proyek kecil ini berlebihan, tapi untuk sistem bernilai besar layak disebut.

Kalau vendor keberatan dengan semua poin di atas tanpa mau menawarkan jalan tengah, itu sinyal yang perlu Anda perhatikan sebelum tanda tangan.

Kasus yang paling sering kami dengar

Polanya hampir selalu sama. Sebuah bisnis memakai aplikasi yang dibuat vendor beberapa tahun lalu. Layanan vendor menurun, atau harganya naik terus, dan klien memutuskan pindah. Vendor baru bertanya hal pertama yang wajar: mana source code-nya. Ternyata tidak ada. Klien menghubungi vendor lama, dan vendor lama memasang harga untuk menyerahkan kode. Kadang angkanya mendekati biaya membangun ulang dari nol.

Posisi klien di titik ini lemah. Kontrak lama diam soal kepemilikan, kode ada di tangan vendor, dan aplikasi harus tetap jalan setiap hari. Kebanyakan akhirnya membayar, atau membangun ulang dari awal. Dua-duanya mahal, dan dua-duanya bisa dicegah dengan satu klausul yang ditulis bertahun-tahun sebelumnya, saat hubungan masih baik dan tidak ada yang merasa terancam.

Praktik serah terima yang sehat

Kepemilikan di atas kertas saja belum cukup. Bentuk serah terimanya juga menentukan seberapa berguna kode itu di tangan Anda.

Minta serah terima lewat repository git lengkap dengan riwayat perubahannya, bukan file zip yang dilempar sekali di akhir proyek. Riwayat commit membantu tim mana pun yang meneruskan aplikasi memahami bagaimana kode itu berkembang. File zip tanpa riwayat memang secara teknis adalah source code, tapi nilainya jauh lebih rendah untuk pengembangan jangka panjang.

Biasakan juga menyimpan salinan sendiri setiap ada rilis besar. Tidak perlu rumit, cukup pastikan ada cadangan kode di penyimpanan yang Anda kendalikan, bukan hanya di server vendor. Kalau suatu hari terjadi apa pun pada vendor, aplikasi Anda tidak ikut hilang.

Di Arrazy sendiri posisinya sederhana: kode custom yang kami tulis untuk klien menjadi milik klien setelah pembayaran lunas, dan serah terima dilakukan lewat repository. Kalau Anda sedang merencanakan pembuatan sistem atau aplikasi dan ingin membahas skema kepemilikan kodenya sejak awal, hubungi kami dan kita bicarakan sebelum kontrak dibuat.

Prinsip yang sama berlaku untuk aplikasi Android dan iOS yang kami buat: repository, file rilis, dan akun Play Console atas nama klien ikut diserahkan. Rinciannya ada di halaman jasa pembuatan aplikasi Android.

Pertanyaan yang sering muncul

Kontrak saya telanjur tidak mengatur soal ini. Bagaimana?

Ajak vendor membuat addendum atau berita acara yang menegaskan kepemilikan dan serah terima kode. Lakukan sekarang, selagi hubungan masih baik, bukan saat Anda sudah berniat pindah. Kebanyakan vendor yang sehat mau menandatanganinya karena isinya memang menegaskan praktik yang wajar.

Apakah boleh minta source code di tengah proyek?

Boleh, dan sebaiknya memang begitu. Akses read ke repository atau salinan berkala di tiap termin pembayaran adalah permintaan yang normal. Vendor yang bekerja rapi tidak keberatan, karena kode yang mereka serahkan bertahap sama dengan kode yang akan diserahkan di akhir.

Database termasuk source code bukan?

Secara teknis bukan, tapi jawabannya lebih tegas: data itu milik Anda. Data pelanggan, transaksi, dan seluruh isi database berasal dari operasional bisnis Anda, apa pun model kepemilikan kodenya. Vendor mana pun tidak punya alasan menahan data Anda, dan Anda berhak minta salinan database kapan saja dalam format yang bisa dipakai ulang.

Kepemilikan source code hanyalah satu bagian dari serah terima proyek yang beres. Akses hosting, domain, dokumentasi, dan akun layanan pihak ketiga juga sering tercecer. Daftar lengkapnya sudah kami tulis di checklist serah terima proyek aplikasi dari vendor. Baca sebelum proyek Anda dinyatakan selesai.

Artikel ini pertama kali terbit di arrazyinovasi.com.

Apa Itu Laravel Volt dan Bagaimana Cara Kerjanya

Arrazy Inovasi — Thu, 24 Sep 2026 22:37:42 +0000

Kalau Anda pernah pakai Livewire di Laravel, mungkin sudah tahu betapa nyamannya bikin komponen reaktif tanpa harus tulis JavaScript. Laravel Volt membawa pengalaman itu selangkah lebih jauh dengan sintaks single-file component yang lebih bersih.

Artikel ini menjelaskan apa itu Laravel Volt, bagaimana cara kerjanya, dan di mana Volt cocok dipakai.

Apa Itu Laravel Volt?

Laravel Volt adalah API baru untuk Livewire v3 yang memungkinkan Anda menulis komponen Livewire dalam satu file Blade, tanpa class PHP terpisah.

Sebelum Volt, sebuah komponen Livewire butuh dua file:

app/Livewire/Counter.php - class dengan logika
resources/views/livewire/counter.blade.php - template

Dengan Volt, keduanya bisa dalam satu file counter.blade.php:

use function Livewire\Volt\{state};

state(['count' => 0]);

$increment = fn() => $this->count++;
$decrement = fn() => $this->count--;

<div>
    <h1>{{ $count }}</h1>
    <button wire:click="increment">+</button>
    <button wire:click="decrement">-</button>
</div>

Lebih ringkas, dan semua yang perlu dibaca ada dalam satu file.

Perbedaan Volt Class API vs Functional API

Volt mendukung dua cara penulisan. Functional API (contoh di atas) lebih ringkas untuk komponen sederhana. Class API cocok untuk komponen yang lebih kompleks karena lebih terstruktur:

use Livewire\Volt\Component;

new class extends Component {
    public int $count = 0;

    public function increment(): void
    {
        $this->count++;
    }

    public function decrement(): void
    {
        $this->count--;
    }
};

Apa Yang Volt Sederhanakan?

Volt bukan framework baru, melainkan layer di atas Livewire v3. Yang berubah:

Satu file per komponen: tidak perlu buka dua file sekaligus saat edit
Co-location: logika dan template ada di satu tempat, lebih mudah dipahami konteksnya
Lebih sedikit boilerplate: tidak perlu bikin class, register namespace, dll.

Yang tetap sama: cara Livewire bekerja (wire:click, wire:model, dan seterusnya) tidak berubah sama sekali.

Kapan Pakai Volt vs Livewire Biasa?

Volt cocok untuk komponen yang:

Logikanya tidak terlalu besar
Tidak perlu di-extend atau di-inherit komponen lain
Berdiri sendiri dan tidak terlalu banyak dependency

Tetap pakai Livewire class biasa kalau:

Komponen butuh extend dari base class kustom
Logikanya sudah terlalu panjang dan butuh dipisah ke service
Tim lebih familiar dengan pola class-based

Tulisan ini pertama kali terbit di blog Arrazy Inovasi Teknologi, tempat kami berbagi tutorial Laravel dan Golang sambil membangun aplikasi untuk klien.

DEV Community: Arrazy Inovasi