Seorang pemilik toko bahan bangunan di Semarang selama bertahun-tahun mencatat stok di buku tulis dan grup WhatsApp. Ketika selisih stok mulai sering terjadi, ia tidak menyewa programmer. Dalam dua pekan, dengan berlangganan sebuah platform no-code, ia punya aplikasi pencatatan barang masuk dan keluar yang bisa dibuka dari ponsel karyawan. Tidak satu baris kode pun ia tulis.
Cerita semacam ini yang membuat istilah low-code dan no-code ramai dibicarakan. Namun yang sering luput dijelaskan adalah apa yang sebenarnya terjadi di balik layar seret-dan-lepas itu — dan di titik mana pendekatan ini berhenti bekerja.
Kode itu tidak hilang, hanya dipindahkan
Ketika pengguna menyeret sebuah kolom "Nama Barang" ke atas kanvas, platform tidak menuliskan kode program untuk pengguna. Yang terjadi lebih sederhana sekaligus lebih terbatas: platform menyimpan pilihan itu sebagai konfigurasi — semacam catatan bahwa ada satu tabel bernama "barang" dengan kolom teks bernama "nama". Konfigurasi inilah yang dibaca ulang oleh mesin platform setiap kali aplikasi dibuka, lalu diterjemahkan menjadi tampilan formulir dan perintah penyimpanan ke database.
Logika bisnis pun bekerja dengan pola serupa. Aturan "jika stok kurang dari 10, kirim notifikasi ke pemilik" tidak ditulis sebagai kode, tetapi dipilih dari rangkaian menu bersyarat: pemicu, kondisi, aksi. Koneksi ke layanan lain — pengiriman WhatsApp, pembayaran, penyimpanan berkas — memakai konektor siap pakai yang di baliknya memanggil API pihak ketiga. Artinya, kode program tetap ada dan tetap kompleks; hanya saja ditulis sekali oleh vendor platform, bukan oleh penggunanya.
Konsekuensinya langsung terasa: pengguna hanya bisa membuat apa yang sudah diantisipasi oleh vendor. Selama kebutuhannya berupa formulir, daftar data, persetujuan berjenjang, dan laporan, pendekatan ini biasanya cukup. Begitu kebutuhannya keluar dari pola tersebut, jalan mulai tertutup.
Di mana low-code masuk
Di situlah low-code berbeda. Platform low-code menyediakan lubang-lubang tempat pengembang menyisipkan kode sendiri. Contoh yang sering muncul di Indonesia cukup spesifik: validasi format NIK 16 digit beserta pemeriksaan kode wilayah, perhitungan pemotongan PPh 21 yang skemanya berubah mengikuti aturan pajak, atau pemanggilan API layanan pemerintah yang membutuhkan penandatanganan permintaan secara khusus. Komponen bawaan biasanya tidak menyediakan itu, sehingga pengembang menulis fungsi pendek — beberapa puluh baris — dan menempelkannya ke alur yang sudah dirancang lewat antarmuka visual.
Pola kerja tim IT internal perusahaan biasanya begini: tampilan, formulir, dan alur persetujuan dibangun secara visual dalam hitungan hari, lalu waktu pengembang dipakai hanya untuk bagian yang benar-benar rumit. Aplikasi pengajuan cuti, pencatatan aset kantor, atau formulir kunjungan pelanggan yang sebelumnya menumpuk di daftar tunggu bisa lebih cepat selesai, karena tidak lagi bersaing dengan sistem inti perusahaan yang menyerap hampir seluruh perhatian tim.
Tagihan yang tumbuh dan pintu keluar yang sempit
Masalah paling sering muncul bukan pada tahap membuat, melainkan pada tahap membesar. Skema harga platform semacam ini umumnya dihitung per pengguna aktif per bulan. Sebuah klinik yang memulai dengan lima staf akan merasa langganannya murah; ketika aplikasi yang sama dipakai 150 orang di lima cabang, angka bulanannya bisa melampaui biaya membangun sistem sendiri.
Pada titik itu, banyak organisasi baru menyadari sempitnya pintu keluar. Data pelanggan biasanya masih bisa diekspor ke format spreadsheet, tetapi logika aplikasi — aturan bersyarat, alur persetujuan, tampilan — tersimpan dalam format milik vendor dan tidak bisa dipindahkan ke platform lain. Migrasi praktis berarti membangun ulang dari nol. Karena itu, pertanyaan "bagaimana cara saya keluar dari platform ini" sebaiknya diajukan sebelum berlangganan, bukan setelah dua tahun data menumpuk.
Tanggung jawab hukum tetap di tangan pemilik aplikasi
Kemudahan teknis tidak menghapus kewajiban hukum. Berdasarkan Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi, pihak yang menentukan tujuan dan mengendalikan pengolahan data berkedudukan sebagai pengendali data pribadi. Ketika sebuah usaha membangun aplikasi pendaftaran pelanggan di platform no-code milik perusahaan asing, statusnya tetap pengendali; platform tersebut umumnya berperan sebagai prosesor. Jika terjadi kebocoran, UU PDP mewajibkan pemberitahuan tertulis kepada subjek data dan lembaga pengawas dalam waktu 3x24 jam — kewajiban yang berada di pihak pemilik aplikasi, bukan pada vendor.
Hal lain yang jarang diperhitungkan adalah status penyelenggara sistem elektronik. Aplikasi yang digunakan untuk melayani publik atau transaksi tunduk pada ketentuan Peraturan Pemerintah Nomor 71 Tahun 2019 dan kewajiban pendaftaran PSE pada Kementerian Komunikasi dan Digital (Komdigi, sebelumnya Kominfo). Untuk sisi keamanan, Badan Siber dan Sandi Negara (BSSN) secara berkala menerbitkan panduan pengamanan sistem elektronik yang dapat dipakai sebagai acuan minimal — termasuk soal pengelolaan hak akses dan pencatatan aktivitas pengguna.
Konteks pasarnya sendiri cukup luas. Survei Asosiasi Penyelenggara Jasa Internet Indonesia (APJII) menunjukkan penetrasi internet nasional sudah melampaui 79 persen populasi, sementara data Badan Pusat Statistik (BPS) mencatat mayoritas pelaku usaha di Indonesia berskala mikro dan kecil — kelompok yang paling mungkin memakai jalur no-code karena tidak punya tim teknologi sendiri.
Yang perlu diperiksa sebelum memilih
- Di negara mana data disimpan, dan apakah vendor bersedia menandatangani perjanjian pengolahan data sesuai UU PDP.
- Apakah data dan konfigurasi bisa diekspor dalam format yang bisa dibaca sistem lain.
- Bagaimana biaya berubah bila jumlah pengguna naik lima hingga sepuluh kali.
- Apakah tersedia pengaturan hak akses per peran, bukan satu akun untuk semua staf.
- Apakah ada catatan aktivitas (log) yang bisa diaudit ketika terjadi insiden.
Low-code dan no-code paling masuk akal untuk aplikasi internal yang alurnya jelas dan datanya tidak terlalu sensitif. Untuk sistem yang menyimpan data keuangan pelanggan, memproses transaksi bernilai besar, atau harus melayani lonjakan pengguna, pengembangan dengan kode penuh oleh pengembang berpengalaman masih menjadi pilihan yang lebih aman — bukan karena lebih modern, tetapi karena kendali penuh atas kode adalah syarat untuk memperbaiki hal yang tidak diantisipasi siapa pun sebelumnya.
