Mengapa Saya Mulai Membangun Member Area Sendiri untuk BOC

Pada pertengahan November 2025, saya mulai melihat kebutuhan baru dari pengguna n8n BOC.

Saya sadar betul bahwa mayoritas user n8n menggunakan n8n untuk automation dan chatbot. Use case-nya bermacam-macam, mulai dari sales, knowledge base, customer support, sampai integrasi proses internal perusahaan.

Namun, mayoritas use case tersebut membutuhkan satu komponen penting: LLM token.

Dari n8n menuju LLM API Token as a Service

Workflow n8n dapat menjadi sangat kuat ketika terhubung dengan Large Language Model. Pengguna dapat membuat chatbot, melakukan klasifikasi pesan, merangkum dokumen, membangun knowledge base, atau mengotomatiskan proses yang membutuhkan pemahaman bahasa.

Masalahnya, pengguna tetap harus menyiapkan LLM API token sendiri, memahami provider yang digunakan, mengatur billing, dan memastikan token tidak tersebar di dalam workflow atau environment yang tidak aman.

Dari kebutuhan tersebut, saya mulai mengeksplorasi kemungkinan menyediakan LLM API Token as a Service di BOC.

Konsepnya adalah memberikan akses LLM melalui layanan yang lebih mudah dikelola pengguna, terintegrasi dengan produk Instant App, dan dapat dikontrol dari satu member area.

Saya ingin pengguna dapat lebih fokus membangun automation, bukan menghabiskan terlalu banyak waktu untuk mengelola credential, provider, limit, dan konfigurasi API.

Benturan dengan sistem WHMCS

Ketika mulai mengeksplorasi skema LLM as a Service, saya menemukan benturan dengan sistem member area yang saat itu digunakan BOC, yaitu WHMCS.

WHMCS sangat kuat untuk kebutuhan billing dan layanan hosting tradisional. Namun, skema LLM API Token as a Service memiliki kebutuhan yang berbeda.

Saya membutuhkan fleksibilitas untuk mengelola hal-hal seperti:

• saldo atau pemakaian token;
• limit penggunaan;
• API key;
• pilihan model LLM;
• usage monitoring;
• paket berbasis konsumsi;
• integrasi dengan Instant App;
• dan kemungkinan menggabungkan beberapa provider LLM.

Ketika kebutuhan produk mulai bergerak keluar dari pola domain, hosting, dan VPS, saya mulai merasakan bahwa struktur WHMCS menjadi semakin membatasi ruang eksplorasi.

Security dan vendor lock-in

Selain keterbatasan model bisnis, saya juga semakin sadar terhadap kelemahan keamanan yang perlu saya perbaiki di sekitar WHMCS dan akses yang terhubung dengannya.

Sebelumnya, saya sudah melakukan instalasi ulang, hardening, migrasi data, review akses, pemasangan 2FA, dan review firewall. Namun, proses tersebut juga membuat saya melihat bahwa security tidak cukup diselesaikan hanya dengan menambahkan beberapa konfigurasi.

Saya perlu memiliki kontrol yang lebih besar terhadap arsitektur member area, modul, integrasi, permission, dan proses pengembangan fitur.

Di sisi lain, vendor lock-in pada sistem existing juga mulai membatasi fleksibilitas layanan Instant App di BOC. Setiap kali saya ingin membangun skema layanan baru, saya harus menyesuaikannya dengan struktur platform yang awalnya dirancang untuk kebutuhan hosting dan billing tradisional.

Bagi saya, ini menjadi sinyal bahwa BOC membutuhkan fondasi member area yang dapat kami kembangkan sendiri.

Keputusan membangun member area sendiri

Karena itu, saya memutuskan untuk mulai mengembangkan member area sendiri untuk BOC.

Keputusan ini bukan berarti saya langsung membuang seluruh fungsi WHMCS. Saya memahami bahwa WHMCS masih menyimpan banyak data dan proses penting yang sudah digunakan pelanggan.

Sebagai tahap awal, member area baru saya jalankan menggunakan database yang sama dengan WHMCS. Pendekatan ini saya gunakan agar proses transisi dapat dilakukan bertahap dan data existing tetap dapat dimanfaatkan.

Namun, menggunakan database yang sama juga membutuhkan kehati-hatian. Saya tidak boleh sembarangan mengubah struktur, menulis data tanpa memahami relasi, atau mengganggu proses existing yang masih berjalan di WHMCS.

Karena itu, pengembangan member area saya lakukan dengan prinsip:

• memahami struktur data existing terlebih dahulu;
• membaca dan menggunakan data secara terkontrol;
• tidak menyalin fitur tanpa memahami alurnya;
• memisahkan logic baru dari bagian yang belum siap dimigrasikan;
• dan menjaga agar proses transisi tidak mengganggu pelanggan.

Tidak semua fitur WHMCS saya bangun ulang

Saya tidak berencana membangun ulang seluruh fitur WHMCS satu per satu.

Banyak fitur WHMCS yang sudah matang untuk kebutuhan tertentu. Membangun ulang semuanya akan membutuhkan waktu besar dan dapat menambah risiko yang tidak perlu.

Saya memilih fitur berdasarkan kebutuhan roadmap BOC, terutama fitur yang berkaitan dengan:

• member area;
• layanan Cloud VPS;
• Instant App Hosting;
• LLM API Token as a Service;
• usage dan billing berbasis pemakaian;
• API key;
• support;
• serta pengelolaan layanan pelanggan.

Dengan fokus tersebut, saya dapat membangun fitur yang benar-benar mendukung arah baru BOC tanpa harus mengejar kesamaan 100 persen dengan WHMCS.

Layout dibuat familiar untuk user existing

Meskipun tidak semua fitur WHMCS dibangun ulang, saya tetap berusaha membuat layout dan penempatan fitur semirip mungkin dengan WHMCS.

Tujuannya sederhana: saya tidak ingin user existing harus belajar ulang seluruh cara penggunaan member area hanya karena sistem di belakangnya berubah.

User sudah terbiasa dengan pola tertentu untuk melihat layanan, mengelola akun, membuka support, dan memeriksa informasi billing. Jika layout baru terlalu berbeda, perubahan teknis di sisi kami akan berubah menjadi beban belajar di sisi pelanggan.

Karena itu, saya mempertahankan pola navigasi dan penempatan fitur yang familiar, sambil menyiapkan fondasi baru untuk kebutuhan yang belum dapat dilayani dengan baik oleh WHMCS.

Member area sebagai fondasi produk baru

Member area sendiri bukan sekadar tampilan baru.

Saya ingin menjadikannya sebagai pintu utama untuk seluruh ekosistem layanan BOC:

• Cloud VPS;
• Managed Cloud VPS;
• n8n Hosting;
• n8n Cloud VPS;
• Supabase Hosting;
• Wuzapi Hosting;
• LLM API Token as a Service;
• dan Instant App lainnya yang akan kami kembangkan.

Dengan member area yang kami bangun sendiri, saya dapat merancang pengalaman pengguna berdasarkan cara kerja produk BOC, bukan hanya menyesuaikan produk BOC ke batasan platform existing.

Proses pengembangan akan saya update berkala

Saya tahu pengembangan member area sendiri bukan pekerjaan kecil.

Ada banyak bagian yang harus saya pikirkan: autentikasi, permission, migrasi data, billing, provisioning, API integration, usage tracking, logging, security, dan support.

Karena itu, saya akan meng-update proses pengembangan ini secara berkala melalui serial Building BOC.

Saya ingin mendokumentasikan bukan hanya hasil akhirnya, tetapi juga keputusan yang saya ambil, kendala yang muncul, bagian yang harus diubah, dan alasan di balik setiap pendekatan teknis.

Saya mulai membangun member area sendiri bukan karena ingin membuat ulang semua hal yang sudah ada, tetapi karena BOC membutuhkan fondasi yang lebih fleksibel untuk membangun produk cloud dan Instant App berikutnya.

Ini adalah bagian dari serial Building BOC—catatan saya saat membangun platform digital BOC dari kebutuhan nyata yang muncul dalam proses transformasi.