Dalam sebulan ke belakang, Insider AI Lab dikembangkan, sebuah headless CMS internal yang lahir dari kendala yang dialami antara tim marketing dan tim developer, di mana setiap perubahan konten landing page maupun jurnal publikasi selalu harus melalui antrean permintaan ke developer. Insider AI Lab hadir sebagai jembatan: memungkinkan tim marketing membuat dan mempublikasikan konten secara mandiri, tanpa mengorbankan kontrol teknis di sisi developer.
Tulisan ini merangkum proses pengembangannya: keputusan-keputusan yang diambil di sepanjang jalan, kendala teknis yang ditemukan, hingga pelajaran yang didapat selama proyek berlangsung.

Tim marketing memerlukan kemampuan untuk mempublikasikan landing page promosi dan jurnal internal secara berkala, tanpa harus menunggu ketersediaan tim developer untuk setiap perubahan konten. Ketergantungan semacam ini memperlambat waktu rilis dan membebani kapasitas tim engineering dengan pekerjaan yang sifatnya repetitif.
Solusinya adalah memisahkan lapisan pengelolaan konten dari lapisan presentasi: tim non-teknis mengelola konten melalui antarmuka admin, sementara struktur data dan aturan render tetap dikontrol developer melalui template yang telah disiapkan. Pendekatan inilah yang mendasari pemilihan headless CMS sebagai solusi.
- Frontend: React + TypeScript + Vite, routing menggunakan TanStack Router (file-based routing), styling dengan Tailwind CSS dan design token kustom, ikon dari Radix UI
- Backend: PocketBase untuk collections, autentikasi, dan API rules
- Deployment: Coolify
- Version Control: Git/GitHub
Proyek dikerjakan secara bertahap melalui pembagian job desc di bawah arahan pembimbing. Setiap kali muncul hal yang kurang jelas, baik terkait fitur maupun keputusan desain, konfirmasi selalu diminta terlebih dahulu sebelum eksekusi dilanjutkan. Pola ini terlihat jelas misalnya ketika fitur import HTML pertama kali diajukan sebagai scope tambahan di luar rencana awal, dan pada diskusi terbuka mengenai perlu-tidaknya subdomain terpisah untuk menyimpan file HTML yang diunggah.
Pada tahap awal, tim marketing dapat membuat landing page melalui form builder dengan tiga pilihan template:
- Template A: bergaya editorial/terang
- Template B: bergaya dark modern, terinspirasi dari giga.ai
- Template C: ditujukan untuk publikasi jurnal

Setelah form builder berjalan, muncul kebutuhan tambahan: bagaimana bila desain landing page sudah selesai dibuat di luar sistem? Dari situ lahir fitur import HTML, dengan sejumlah batasan yang disepakati bersama pembimbing:
- Hanya menerima satu file.html tunggal, tanpa dukungan folder aset (gambar/CSS wajib menggunakan URL absolut/eksternal)
- Halaman hasil import bersifat read-only, hanya dapat diganti filenya secara utuh melalui tombol "Ganti File HTML"
- Konten dirender melalui <iframe sandbox="allow-scripts"> tanpa allow-same-origin, sehingga skrip pada halaman yang diimpor tetap dapat berjalan untuk kebutuhan interaktivitas, namun terisolasi dari cookie, localStorage, dan DOM situs utama
Alur penggunanya: unggah file → pratinjau nama file → pengisian judul dan slug → klik "Upload & Buat Landing Page" → pengalihan ke halaman detail yang menampilkan metadata, pratinjau iframe, dan tombol penggantian file.
Satu pertanyaan yang masih terbuka hingga saat ini: apakah file hasil unggahan perlu dilayani dari subdomain terpisah sebagai lapisan keamanan tambahan. Hal ini masih didiskusikan lebih lanjut dengan pembimbing.



Pada sisi publik, tersedia halaman /user yang menampilkan seluruh landing page dan jurnal yang telah dipublikasikan tanpa memerlukan login. Halaman ini dilengkapi tab switching antar jenis konten, pencarian, filter kategori (khusus jurnal), pengurutan, dan pagination.
Pada sisi admin, terdapat halaman "Aktivitas Publikasi" dengan antarmuka yang setara dengan katalog publik, dengan perbedaan bahwa halaman ini memerlukan autentikasi dan ditambahkan sebagai entri baru pada sidebar navigasi admin.



Selain sisi fitur, penyiapan infrastruktur menjadi bagian tersendiri dari proyek ini: memastikan aplikasi yang sudah dibangun dapat diakses secara publik melalui domain resmi, berjalan stabil, dan terlindungi koneksi HTTPS.
Aplikasi (headless CMS beserta halaman publik landing page dan jurnal) dikemas dalam satu container menggunakan Docker Compose, dengan PocketBase sebagai binary yang di-build langsung di dalam image saat proses deployment. Proses deploy dijalankan melalui Coolify, yang menangani build image, menjalankan container di server, serta mengatur reverse proxy (Traefik) dan penerbitan sertifikat SSL secara otomatis lewat Let's Encrypt begitu domain terkonfigurasi.
Karena akses ke akun pengelola domain produksi (ai-lab.id) belum diberikan pada tahap ini, proses penyambungan domain diuji coba terlebih dahulu menggunakan subdomain riset pada domain lain yang telah tersedia aksesnya. Pendekatan ini dipilih agar seluruh alur — mulai dari penambahan DNS record, konfigurasi domain pada resource Coolify, hingga verifikasi SSL — telah teruji dan dapat langsung direplikasi begitu akses domain produksi diberikan, tanpa perlu coba-coba di domain resmi perusahaan.
Alur yang ditempuh:
1. Menambahkan DNS record (CNAME, mengarah ke hostname server deployment) pada domain riset
2. Menambahkan domain tersebut pada konfigurasi resource aplikasi di Coolify
3. Melakukan redeploy agar Coolify meregenerasi konfigurasi reverse proxy dan sertifikat SSL
4. Verifikasi akhir dengan mengakses domain tersebut langsung di browser, memastikan halaman termuat dan sertifikat SSL valid


Sejumlah kendala teknis ditemukan dan diperbaiki sepanjang proses pengembangan:
1. Konfigurasi API rules PocketBase yang terlalu ketat: Aturan View/Create yang terlalu restriktif pada beberapa collection menyebabkan sejumlah bug fungsional, di antaranya data pengguna yang tampil sebagai "Tanpa nama" pada antarmuka, serta gangguan pada alur pendaftaran pengguna baru. Perbaikan dilakukan dengan meninjau ulang dan menyesuaikan aturan akses pada level collection. Pelajaran pentingnya: setiap kali terjadi perubahan skema data, konfigurasi API rules perlu diverifikasi ulang.
2. Asumsi struktur data jurnal yang keliru: Field content_sections pada collection jurnal awalnya diasumsikan berbentuk array datar. Struktur sebenarnya adalah objek JSON bertingkat: { sections: [{ heading, body }] }. Kesalahan asumsi ini sempat menyebabkan kegagalan penayangan konten jurnal, dan baru teridentifikasi setelah struktur data ditelusuri ulang secara langsung dari skema collection.
3. Sejumlah isu pada halaman katalog publik: Selama tahap debugging, ditemukan beberapa isu: perilaku filter kategori pada tab jurnal, kolom pencarian yang belum berfungsi sebagaimana mestinya, serta penentuan tab default saat halaman pertama kali dimuat. Seluruh isu ini diselesaikan sebelum halaman katalog publik dianggap siap digunakan.

4. Proses build sempat gagal saat deployment: Salah satu proses deployment sempat berhenti di tengah tahap instalasi dependency dengan exit code 255, tanpa pesan error yang eksplisit pada log. Setelah dilakukan redeploy ulang, proses berjalan lancar tanpa perubahan konfigurasi apa pun, mengindikasikan kendala tersebut bersifat sementara pada sisi resource server, bukan kesalahan pada konfigurasi aplikasi. Pelajaran pentingnya: kegagalan build tidak selalu berarti ada yang salah dengan kode atau konfigurasi — memeriksa log secara menyeluruh dan mencoba redeploy adalah langkah pertama yang wajar sebelum menelusuri lebih jauh.

5. Konsistensi penamaan subdomain antara DNS dan konfigurasi aplikasi: Nama subdomain yang didaftarkan sebagai DNS record harus persis sama dengan yang dikonfigurasi pada pengaturan domain di Coolify. Perbedaan sekecil apa pun pada penamaan menyebabkan sertifikat SSL gagal diterbitkan meskipun DNS record sudah aktif dan resource aplikasi berjalan normal.
Proyek ini juga telah melalui tahap presentasi internal, dengan skrip demo dan data dummy yang disiapkan khusus untuk memperagakan alur pembuatan konten (baik melalui builder maupun import HTML), publikasi, hingga penayangan pada katalog publik.
- Menentukan apakah file HTML hasil import perlu dilayani dari subdomain terpisah demi lapisan keamanan tambahan
- Pengujian masih dilakukan secara manual, belum mencakup automated testing
- Model akses masih bersifat kolaboratif tanpa kepemilikan individual, dengan struktur peran yang masih datar belum mendukung kontrol akses granular
- Sejumlah item pada job desc berikutnya masih menunggu arahan pembimbing
Insider AI Lab berhasil menghadirkan CMS headless dengan dua jalur pembuatan konten: form builder bertemplate dan import HTML mentah yang disatukan secara konsisten pada sisi publik maupun sisi admin. Pola kerja konfirmasi ke pembimbing sebelum eksekusi terbukti efektif dalam menjaga cakupan proyek tetap terkendali di tengah sifat pengembangan yang iteratif dan bertahap.