Lantara v2

Permasalahan

IKN Nusantara adalah ibu kota baru Indonesia yang dibangun dari awal, masih dalam konstruksi aktif. Otorita IKN harus menerbitkan perizinan di 31 sektor yang diatur: layanan sosial, kesehatan, pendidikan, lingkungan, dan lainnya. Di kebanyakan instansi pemerintah, setiap jenis izin memiliki workflow, form, dan persyaratan dokumen yang dikodekan secara keras di codebase. Ketika regulasi berubah — dan di kota baru, perubahan itu terjadi terus-menerus — itu berarti butuh developer, migrasi database, dan deployment.

Sistem ini melayani tiga audiens sekaligus: warga dan pelaku usaha yang mengajukan izin, staf pemerintah yang memverifikasi, dan administrator instansi yang menetapkan aturan. Dan aturan itu ditetapkan oleh undang-undang dan keputusan menteri, bukan oleh developer. Maka persyaratan utamanya tegas: administrator non-teknis harus bisa mendefinisikan workflow perizinan, skema form, dan daftar dokumen sepenuhnya melalui UI — tanpa developer, tanpa deployment.

Pendekatan

Engine — konfigurasi, bukan kode

Alih-alih tabel per jenis izin, semua konfigurasi perizinan tersimpan dalam lima model terkait: Sektor, PermitType, WorkflowStage, FormField, dan DocumentRequirement. Menambahkan jenis izin baru adalah operasi entri data. Administrator dapat mengkonfigurasi izin kesehatan enam tahap dengan dua belas dokumen yang dipersyaratkan dan form kustom — tanpa migrasi, tanpa deployment, tanpa pull request.

Data form pada setiap pengajuan disimpan sebagai JSON field, divalidasi saat runtime terhadap skema field yang aktif. Ketika admin mengubah skema izin, pengajuan yang sedang berjalan terlindungi: pada saat pengajuan, versi skema saat itu disalin secara penuh ke catatan pengajuan. Warga yang sudah mengajukan tidak pernah mengalami perubahan bentuk form di tengah proses, dan audit tetap deterministik — Anda selalu tahu persis apa yang ditanyakan saat seseorang mengajukan.

RBAC tanpa enum

Permission staff adalah string yang dihasilkan seperti verifikasi_teknis:izin_posyandu, berasal dari kunci tahapan workflow dan kunci jenis izin. Tidak ada if role == "verifier" di mana pun dalam codebase. Kelas permission DRF memeriksa tahap pengajuan saat ini terhadap string role yang ditetapkan ke pengguna. Ketika jenis izin baru ditambahkan melalui UI, slot role yang tepat otomatis tersedia — tanpa perubahan kode.

SLA sebagai concern utama

Setiap tahapan workflow memiliki field sla_hours; setiap jenis izin memiliki sla_days total. Task Celery Beat menyapu pengajuan secara berkala, menghitung ulang tenggat SLA menggunakan kalender hari kerja yang memperhitungkan hari libur nasional dan akhir pekan, dan mengirimkan notifikasi ketika pengajuan mendekati batas atau sudah melewati batas. Antrian verifikator menampilkan kartu pengajuan yang secara visual menua dari kuning ke merah seiring tenggat mendekati. Pintasan keyboard (j/k untuk navigasi, a/r/d untuk setujui/revisi/tolak) memungkinkan staf memproses tanpa menyentuh mouse.

Verifikasi yang akuntabel

Proses review dirancang untuk bertahan di kantor pemerintah yang sesungguhnya. Verifikator dapat meng-claim sebuah pengajuan untuk dikerjakan secara eksklusif; claim yang usang otomatis dilepas setelah tidak aktif, dan setiap claim serta keputusan mencatat atribusi pelakunya, sehingga dua verifikator tidak akan pernah diam-diam bertabrakan pada berkas yang sama. Revisi bersifat per-field: setiap field yang ditandai membawa catatan dan tenggatnya sendiri, dan pemohon melihat nilai asli di samping diff sebelum→sesudah, bukan sekadar satu komentar generik "mohon direvisi". Dan karena sebagian izin secara hukum membutuhkan tanda tangan dari dua bidang teknis berbeda, penugasan verifikator dilingkup per tahapan workflow — memastikan tidak ada satu verifikator pun yang bisa menyetujui kedua tahap review-nya sendiri.

Dua register, satu renderer dinamis

Permukaan publik — halaman landing, katalog izin, dan halaman validasi publik — menggunakan palet biru royal yang imersif dengan hero animasi, scroll-reveal, dan glassmorphism, sesuai sebagai pintu depan digital sebuah ibu kota negara. Permukaan terautentikasi — portal pemohon, workspace verifikator, dan admin engine builder — tenang dan padat; verifikator yang memproses lima puluh izin sehari butuh kejelasan, bukan dekorasi. Keduanya disuplai oleh satu komponen React <DynamicForm> yang mengambil skema FormField[] izin dari API dan membangun validasi zod saat runtime, menangani dua belas jenis field (text, NIK, NPWP, telepon, geolokasi, unggah file, select, dan lainnya). Menambahkan jenis izin tidak memerlukan kode frontend sama sekali.

Melampaui brief — sistem antrean fisik

Begitu permit engine bisa didemonstrasikan, satu celah tampak jelas: engine hanya memodelkan workflow daring yang digerakkan dokumen dan berlangsung berhari-hari. Ia tidak punya konsep warga yang berjalan masuk ke gedung dan mengambil nomor antrean — yang justru dibutuhkan Mal Pelayanan Publik yang menampung OIKN dan instansi mitra seperti BPJS dan kantor pajak. Maka saya melingkup dan merilis MPP Antrean, sistem antrean walk-in/daring lengkap, sebagai bounded context yang sengaja diisolasi: aplikasi Django tersendiri, model tersendiri, RBAC tersendiri, dan tanpa foreign key ke domain perizinan. Ia menangani ticketing kiosk, check-in QR, triase petugas loket, serta alur panggil/panggil-ulang/layani, dengan status langsung yang didorong lewat lapisan WebSocket Django Channels yang sudah ada. Satu detail keadilan yang menarik: warga yang memesan daring tetapi datang terlambat diturunkan kembali ke pool walk-in berdasarkan waktu kedatangan aktual alih-alih tiketnya dibatalkan — yang berarti pembagian kuota daring/walk-in harus ditegakkan saat reservasi, bukan saat pelayanan.

Hasil

Empat fase pembangunan awal (P0 scaffold hingga P4 hardening) telah dirilis, dan pengembangan berlanjut melampaui brief ke sebuah pass khusus security-hardening, sapuan aksesibilitas yang luas, dan modul MPP Antrean yang berdiri sendiri — 241 commit dalam kurang lebih tiga minggu, mencakup 13 aplikasi Django dan ~30.000 baris. Seluruh sistem dapat didemonstrasikan dari docker compose up yang baru: migrasi berjalan, ~2.200 data master KBLI dimuat, 46 izin sampel di tiga sektor ter-seed, tenant dan loket antrean demo ter-seed, dan akun superadmin dibuat. Siapa pun dapat memindai QR code izin yang diterbitkan di halaman validasi publik untuk mengkonfirmasi keasliannya tanpa perlu login. Zonasi spasial RDTR dan tanda tangan digital tertanam (TTE) sudah terpasang di balik feature flag, menunggu kemitraan berbagi data dan instansi eksternal sebelum aktivasi produksi. Repositori bersifat privat; target deployment adalah infrastruktur milik Otorita IKN sendiri.