Saya Tahu Apa yang Dibutuhkan Agensi — Jadi Saya Bangun Multi-Tenancy di Hari 2

21 Agustus 2025. Hari 2 membangun STRAŦUM.

Saya duduk di meja dengan satu AI agent yang berfungsi (Business Strategy), autentikasi dasar, dan data model yang sangat sederhana. Kopi mulai dingin. Saya tahu persis untuk siapa saya ingin membangun: SME yang butuh bantuan marketing AI, DAN agensi yang bisa menggunakannya lintas multiple klien.

Kedua audiens. Dari Hari 1.

Setelah 20 tahun bekerja di sisi agensi, saya memahami apa yang sebenarnya dibutuhkan agensi — bukan versi marketing yang mengkilap, tapi realitas berantakan mengelola 10-15 klien dengan strategi berbeda, brand guidelines berbeda, segalanya berbeda. Saya juga tahu SME sangat membutuhkan bantuan strategis yang terjangkau.

Tapi di Hari 2, menatap data model sederhana saya, saya menyadari sesuatu yang tidak nyaman: membangun untuk kedua audiens berarti membangun arsitektur multi-tenant. Sekarang. Bukan nanti.

Pada akhir hari, saya sudah berkomitmen pada keputusan yang akan melipattigakan kompleksitas development dan memperpanjang timeline berminggu-minggu.

Saya membangun arsitektur multi-tenant dari Hari 2.

Apakah ini ambisius atau gila? Jujur, saya tidak yakin. Saya masih belum 100% yakin. Tapi ini cerita kenapa keputusan itu — dibuat dengan hampir tidak ada produk yang berfungsi — ternyata menjadi salah satu pilihan teknis terpenting yang saya buat.

Kenapa Kedua Audiens? 20 Tahun Pengalaman Agensi

Visinya tidak pernah SME-only. Dari awal, saya ingin membangun untuk dua audiens berbeda:

SME (Bisnis kecil, 1-30 karyawan) — Co-Founder Strategis yang Terjangkau:

- Tidak mampu bayar agensi marketing atau konsultan

- Tidak punya keahlian marketing strategis

- Butuh quick win tanpa learning curve

Agensi (Mengelola 5-15+ klien) — Scale Kapasitas Strategismu, Bukan Headcount:

- Tenggelam dalam pekerjaan strategi lintas multiple klien

- Butuh framework konsisten yang scale

- Memerlukan isolasi data lengkap antar klien

Kenapa agensi? Karena saya menghabiskan 20 tahun di sisi agensi. Saya tahu sakitnya secara langsung.

Saya sudah melihat strategist menangani 12 klien dengan 12 brand guidelines berbeda, copy-paste konteks antar tool, berdoa mereka tidak secara tidak sengaja mengirim strategi yang salah ke klien yang salah. Saya sudah menyaksikan agensi kehilangan orang baik karena burnout karena tidak ada cara untuk scale pemikiran strategis tanpa scale headcount.

Dan jujur? Saya ingin menantang diri sendiri. Membangun untuk SME saja akan lebih sederhana — satu pengguna, satu organisasi, routing straightforward. Membangun untuk agensi berarti dashboard multi-klien, isolasi data, permission berbasis role, semuanya client-scoped.

Saya ingin membangun sesuatu yang kompleks. Sesuatu yang benar-benar memecahkan masalah sulit yang sudah saya lihat selama dua dekade.

Realisasi Hari 2: Kamu Tidak Bisa Retrofit Multi-Tenancy

Ini yang saya pahami di Hari 2, menatap data model sederhana saya:

Arsitektur SME (apa yang saya punya):

```
users → campaigns → agent_outputs
```

Arsitektur multi-tenant (apa yang saya butuhkan untuk agensi):

```
organizations (SME atau AGENCY)
  ↓
clients (khusus agensi)
  ↓
campaigns
  ↓
agent_outputs (dengan org_id DAN client_id)
```

Perbedaannya bukan hanya "tambah beberapa kolom." Ini data model yang secara fundamental berbeda.

Kalau saya membangun untuk SME dulu dan menambah dukungan agensi nanti, saya akan menatap:

- Migrasi setiap tabel yang ada untuk menambah `org_id`

- Retrofit RLS policies di seluruh database

- Menulis ulang frontend routing untuk konteks klien

- Menguji ulang semuanya dengan skenario multi-tenant

Itu bukan penambahan fitur. Itu rewrite.

Semakin lama saya menunggu, semakin mahal retrofit-nya. Hari 2 itu murah. Hari 60 akan menyakitkan. Hari 200 akan jadi "mungkin kita buat produk terpisah saja untuk agensi."

Jadi saya membuat keputusan: bangun multi-tenant dari Hari 2, atau terima bahwa agensi tidak akan pernah jadi warga kelas satu.

Trade-Off: Apa yang Sebenarnya Dikorbankan Multi-Tenancy

Ini bagian di mana saya seharusnya berhenti dan bertanya: "Kamu yakin soal ini? Kamu punya SATU agent yang berfungsi. SATU."

Tapi saya tidak berhenti. Malah, saya mulai menulis schema SQL seperti orang kesetanan. Multi-tenancy di Hari 2 berarti menerima biaya yang akan membuat orang waras mana pun mempertimbangkan ulang:

Biaya 1: Kompleksitas Development (3X)

Setiap tabel butuh `org_id`. Tabel agensi butuh `client_id`. RLS policies butuh kedua filter. Setiap query, setiap API endpoint, setiap frontend route — semuanya harus multi-tenant aware.

Estimasi peningkatan kompleksitas: 3X waktu development untuk fitur yang sama.

(Spoiler: Sebenarnya lebih dekat ke 4X. Saya meremehkan. Klasik saya. :P)

Biaya 2: Timeline Development yang Diperpanjang

Membangun untuk kedua audiens dari Hari 1 berarti jalan lebih panjang menuju peluncuran. Ini tampilannya:

Timeline:

- 20 Agustus: Mulai membangun (multi-tenant dari Hari 1)

- 15 September: 4 minggu berjalan, 3 agent berfungsi, menargetkan Oktober

- Oktober: Sakit 10 hari, tidak bisa coding

- 5 November: Peluncuran Private Alpha (total 75 hari)

Yang ditambahkan multi-tenancy:

- Schema routing antara tabel public dan agency

- RLS policies di setiap tabel (berakhir dengan 83 di 26 tabel)

- Propagasi konteks klien melalui setiap agent

- Pola routing ganda (URL SME vs agensi)

Apakah saya akan meluncurkan lebih cepat dengan arsitektur SME-only? Mungkin 3-4 minggu lebih cepat. Tapi lalu saya akan menatap rewrite ketika agensi mengetuk pintu.

Biaya 3: Kebutuhan Keamanan (Risiko Lebih Tinggi)

Isolasi data SME itu standar. Isolasi data agensi itu mission-critical.

Kebutuhan yang ditambahkan:

- 83 RLS policies di 26 tabel

- Isolasi level schema (schema public vs agency)

- Database router function untuk setiap operasi CRUD

- Comprehensive audit logging

- Opsi multi factor authenticator

Kompleksitas keamanan: 5X lebih tinggi dari SME-only.

Saya menghabiskan lebih banyak waktu untuk Row-Level Security policies daripada development AI agent yang sebenarnya beberapa minggu. Biarkan itu meresap.

Biaya 4: Kompleksitas Testing (2X Test Case)

Setiap fitur butuh testing untuk:

- ✅ Flow SME (lebih sederhana)

- ✅ Flow agensi (client-scoped)

- ✅ Isolasi data (Nike ≠ Adidas)

- ✅ Batasan permission (bisakah agensi lihat data SME? Tidak.)

Maintenance testing: Dua kali lipat.

Tahu apa yang seru? Menulis tes yang sama dua kali dengan konteks yang sedikit berbeda. Kata tidak ada orang.

---

Kenapa Saya Tetap Membuat Trade-Off Itu

Jadi biar saya luruskan: 3X kompleksitas, timeline diperpanjang, 5X overhead keamanan, testing dua kali lipat... dan saya tetap melakukannya?

Ya. Ini pemikirannya (setidaknya seperti itu):

Alasan 1: Retrofit Itu Mimpi Buruk

Hari 2: Hampir tidak ada kode yang ditulis. Data model masih fleksibel. Tidak ada pengguna untuk dimigrasi.

Hari 60: 45 tabel, 200k baris kode, 15 pengguna alpha. Menambah multi-tenancy akan membutuhkan menulis ulang setengah codebase.

Pelajaran: Keputusan arsitektural semakin sulit diubah secara eksponensial seiring waktu.

Biaya di Hari 2: ~5 jam untuk mendesain ulang data model.

Biaya di Hari 60: ~200 jam untuk refaktor semuanya.

Saya sudah melihat perusahaan mencoba retrofit multi-tenancy. Itu brutal. Kamu pada dasarnya membangun ulang pesawat sambil terbang. Dengan penumpang. Yang membayarmu.

Alasan 2: Saya Benar-Benar Memahami Agensi

Ini bukan riset pasar teoretis. Saya menghabiskan 20 tahun menyaksikan agensi berjuang dengan masalah yang persis ini.

Saya tahu mereka butuh:

- Isolasi data lengkap (klien 1 tidak bisa lihat strategi klien 2)

- Semuanya client-scoped (brand guidelines, persona, campaign)

- Akses berbasis role (account manager vs strategist)

- Potensi white-label untuk presentasi klien

Saya bisa membangun ini dengan benar karena saya sudah merasakan sakitnya. Itu bukan keunggulan yang ingin saya sia-siakan dengan shipping SME-only dan "menambah agensi nanti."

Alasan 3: Tantangannya Adalah Intinya

Ini sesuatu yang tidak sering saya katakan: saya menginginkan kompleksitasnya.

Saya founder paruh baya dengan keluarga, bukan anak 22 tahun yang bisa bertahan dengan minuman energi dan tanpa tidur. Kalau saya akan menghabiskan setahun membangun sesuatu, lebih baik sesuatu yang menantang saya. Sesuatu yang membuat saya bangga secara teknis.

Arsitektur multi-tenant dengan isolasi data yang proper, RLS policies, schema routing — itu sulit. Itu menarik. Itu jenis masalah engineering yang membuat saya tetap engaged jam 2 pagi.

Membangun SME-only akan lebih cepat. Tapi apakah saya akan termotivasi mendorong melewati bagian yang sulit? Mungkin tidak.

Alasan 4: Kedua Audiens Membuat Satu Sama Lain Lebih Baik

SME dan agensi bukan use case yang bersaing. Mereka komplementer:

- Agensi memvalidasi produk: Kalau agensi mempercayainya dengan data klien, SME juga akan

- SME memberikan volume: Lebih banyak pengguna berarti lebih banyak feedback, iterasi lebih cepat

- Arsitektur melayani keduanya: Team account, permission role, dan white-label bekerja untuk kedua audiens

Membangun untuk keduanya berarti membangun solusi lengkap, bukan versi yang disederhanakan yang akan saya outgrow.

Alasan 5: Future-Proofing

Bahkan di luar agensi, arsitektur multi-tenancy memungkinkan:

- Team account (SME dengan multiple pengguna)

- Partnership reseller

- Peluang white-label

- Penjualan enterprise (kalau kita mau ke sana)

Option value: Multi-tenancy membuka model bisnis yang bahkan tidak bisa saya bayangkan di Hari 2.

Implementasi: Seperti Apa Keputusan Arsitektur Hari 2

Ini yang sebenarnya saya bangun pada 21 Agustus:

Schema Database (Keputusan Inti)

```sql
-- Tabel organizations (SME atau AGENCY)
CREATE TABLE organizations (
  id UUID PRIMARY KEY,
  name TEXT,
  type TEXT CHECK (type IN ('SME', 'AGENCY')),  -- Pembeda kritis
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Tabel clients (khusus agensi)
CREATE TABLE clients (
  id UUID PRIMARY KEY,
  org_id UUID REFERENCES organizations(id),  -- Agensi mana yang memiliki ini
  company_name TEXT,
  slug TEXT UNIQUE,  -- Untuk URL routing
  created_at TIMESTAMPTZ DEFAULT NOW(),

  -- Constraint: Hanya agensi yang bisa punya klien
  CONSTRAINT clients_agency_only CHECK (
    (SELECT type FROM organizations WHERE id = org_id) = 'AGENCY'
  )
);

-- Tabel campaigns (multi-tenant aware)
CREATE TABLE campaigns (
  id UUID PRIMARY KEY,
  org_id UUID REFERENCES organizations(id),  -- Selalu wajib
  client_id UUID REFERENCES clients(id),      -- Wajib untuk agensi, null untuk SME
  name TEXT,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Output agent (multi-tenant + client-scoped)
CREATE TABLE agent_outputs (
  id UUID PRIMARY KEY,
  org_id UUID REFERENCES organizations(id),
  client_id UUID REFERENCES clients(id),
  campaign_id UUID REFERENCES campaigns(id),
  agent_type TEXT,
  content JSONB,
  created_at TIMESTAMPTZ DEFAULT NOW()
);
```

Keputusan kunci di Hari 2:

- `org_id` di setiap tabel (memungkinkan RLS)

- `client_id` nullable (SME tidak punya klien)

- Diskriminator `type` di organizations (SME vs AGENCY)

- Constraint: Hanya agensi yang bisa membuat klien

Row-Level Security (Perencanaan Hari 2)

```sql
-- RLS policy untuk campaigns (isolasi multi-tenant)
CREATE POLICY campaigns_org_isolation ON campaigns
  FOR ALL TO authenticated
  USING (
    org_id = get_user_org_id() AND
    (client_id IS NULL OR client_id IN (SELECT id FROM clients WHERE org_id = get_user_org_id()))
  );
```

Policy ini memastikan:

- ✅ Pengguna hanya melihat campaign dari organisasi mereka

- ✅ Pengguna agensi tidak bisa lihat campaign SME

- ✅ Agensi tidak bisa lihat klien satu sama lain

Biaya: Menulis 5 RLS policy awal di Hari 2. Akhirnya tumbuh ke 83 saat peluncuran.

URL Routing (Multi-Tenant dari Hari 1)

```typescript
// Struktur frontend routing (direncanakan Hari 2)

// Route SME (sederhana)
/campaigns/:campaignId
/agents/strategy/:campaignId

// Route agensi (client-scoped)
/clients/:clientSlug/campaigns/:campaignId
/clients/:clientSlug/agents/strategy/:campaignId
```

Struktur URL ini memungkinkan:

- ✅ Konteks klien di setiap URL (agensi)

- ✅ Pemisahan jelas antara flow SME dan Agensi

- ✅ URL yang bisa di-bookmark dan di-share

- ✅ Analytics tracking per klien

Hasilnya: Apakah Terbayar?

Tanggal peluncuran: 5 November 2025 (75 hari dari mulai)

Overhead development dari multi-tenancy:

- Desain schema dan migrasi

- 83 RLS policies di 26 tabel

- Database router function

- Pola routing ganda (URL SME vs agensi)

- Propagasi konteks klien

Dengan Claude Code dan Gemini 2.5 Pro, coding aktualnya lebih cepat dari yang bisa saya lakukan sendirian. Tapi debugging RLS policies yang seharusnya berfungsi tapi tidak? Itu masih menyakitkan jam 2 pagi terlepas dari bantuan AI.

Yang saya punya sekarang:

- Isolasi data lengkap antar organisasi

- Arsitektur siap-agensi dengan client scoping

- 83 RLS policies di 26 tabel

- Routing level schema (schema public vs agency)

- Potensi white-label yang terbangun dari Hari 1

- Produk yang sungguh-sungguh bisa melayani SME dan agensi

Worth it?

Tanya saya dalam 6 bulan ketika saya punya pelanggan aktual yang membayar uang aktual. Saat ini saya di private alpha dengan 15+ pengguna, masih belajar apa yang bekerja dan apa yang tidak.

Tapi ini yang saya tahu: saya punya arsitektur untuk melayani kedua audiens dengan proper. Kalau saya membangun SME-only dan mencoba menambah agensi nanti, saya akan menatap rewrite 3 bulan sekarang. Alih-alih, saya fokus pada product-market fit, bukan hutang arsitektural.

Itu terasa seperti trade-off yang tepat.

Framework: Kapan Membangun Multi-Tenancy Lebih Awal

Tidak setiap produk butuh multi-tenancy di Hari 2. Gunakan framework ini:

Bangun Multi-Tenancy Lebih Awal Jika:

✅ Target market termasuk agensi/reseller (nilai lebih tinggi per pelanggan)

✅ Isolasi data kritis (kebutuhan legal/compliance)

✅ B2B dengan team account kemungkinan (model Slack, Figma)

✅ Peluang white-label ada (strategi GTM reseller)

✅ Penjualan enterprise mungkin (butuh multi-client dari Hari 1)

Lewati Multi-Tenancy Lebih Awal Jika:

❌ Produk B2C (pengguna individual, tidak ada hierarki organisasi)

❌ MVP butuh kecepatan (test product-market fit dulu)

❌ Tidak ada use case tim/agensi (tool single-player)

❌ Data model sederhana (menambah org_id nanti mudah)

❌ Solo founder yang belajar (kompleksitas mungkin terlalu banyak)

Pelajaran: Bangun untuk Keahlianmu

1. Pengetahuan Audiens Harus Menggerakkan Arsitektur

Jangan desain untuk pengguna hipotetis. Desain untuk pengguna yang benar-benar kamu pahami.

Keunggulan saya: 20 tahun pengalaman agensi berarti saya tahu persis apa yang dibutuhkan agensi — isolasi data, client scoping, akses berbasis role.

Pendekatan salah: "Mari bangun untuk SME dulu dan tambah agensi nanti ketika kita memahami mereka"

Pendekatan benar: "Saya sudah memahami agensi. Bangun untuk mereka sekarang selagi murah."

Kalau kamu punya keahlian mendalam di segmen pasar, gunakan. Jangan tunda ke "yang lebih sederhana dulu."

2. Kompleksitas Awal Mengalahkan Refactoring Terlambat

Biaya arsitektur Hari 2: 5 jam mendesain ulang data model.

Biaya arsitektur Hari 60: 200 jam refaktor semuanya.

Perbedaan 40X.

Kalau kamu 80% yakin akan butuh multi-tenancy, bangun lebih awal. Semakin lama menunggu, semakin mahal.

3. Tantangan Teknis Bisa Jadi Motivasi

Yang satu ini personal: saya ingin membangun sesuatu yang sulit.

Arsitektur multi-tenant dengan RLS policies, schema routing, dan isolasi data yang proper — itu engineering yang menarik. Itu membuat saya tetap engaged melewati bagian yang sulit.

Kalau kamu solo founder, jangan remehkan motivasi. Membangun sesuatu yang menantangmu mungkin lebih bernilai dari shipping lebih cepat.

4. Arsitektur Memungkinkan Model Bisnis

Multi-tenancy bukan hanya keputusan teknis. Ini memungkinkan:

- Tier harga agensi (kapanpun saya menentukan harga)

- Peluang white-label

- Potensi penjualan enterprise

- Team account untuk SME

Arsitektur = business optionality dalam bentuk kode.

5. Solo Founder Bisa Membangun Multi-Tenant

"Multi-tenancy terlalu kompleks untuk satu orang" → Salah.

Dengan tool modern (Supabase RLS, database function, AI-assisted development), solo founder bisa membangun multi-tenancy grade enterprise.

Biaya waktu: 70 hari (paruh waktu).

Yang kamu dapatkan: Isolasi data yang nyata, bukan hack yang akan kamu sesali nanti.

Worth it kalau kamu serius soal melayani kedua audiens

Pikiran Akhir

Hari 2 terlalu awal untuk tahu apakah STRAŦUM akan berhasil. Saya punya satu agent. Tidak ada pengguna. Tidak ada validasi. Hanya 20 tahun pengalaman agensi yang memberi tahu saya apa yang sebenarnya dibutuhkan agensi.

Timeline yang diperpanjang terasa menyakitkan kadang. Menyaksikan peluncuran lain sementara saya masih debugging RLS policies dan menulis database router function? Frustrasi bahkan tidak mulai menggambarkannya. Ada hari-hari di mana saya mempertanyakan apakah kompleksitasnya worth it.

Tapi ini yang saya tahu sekarang: membangun untuk kedua audiens dari Hari 1 adalah keputusan yang tepat. Bukan karena kalkulasi unit economics yang cerdas — saya masih tidak tahu pricing apa yang akan bekerja. Tapi karena saya punya arsitektur untuk benar-benar melayani kedua audiens dengan proper.

Multi-tenancy di Hari 2 bukan hanya keputusan teknis. Itu taruhan untuk membangun bagi pengguna yang benar-benar saya pahami, bukan pengguna hipotetis yang akan saya cari tahu nanti.

Apakah taruhan itu terbayar?

Saya masih di Private Alpha dengan 15+ pengguna. Saya belum punya jawabannya. Tapi saya bisa bilang ini: ketika agensi menghubungi dan bertanya "bisakah kami menggunakan ini untuk multiple klien dengan isolasi data yang proper?" saya bisa bilang ya. Saya tidak harus bilang "kami sedang mengerjakannya."

Itu terasa seperti fondasi yang tepat.

Waktu akan menjawab apakah saya ambisius atau hanya keras kepala. (Mungkin sedikit keduanya, jujur.) :)

Pernahkah kamu membuat taruhan arsitektur lebih awal yang terasa terlalu ambisius saat itu — dan apakah terbayar? Saya ingin dengar ceritamu.

Salam,

Chandler

Seri arsitektur STRAŦUM: Keputusan Hari 2 ini baru permulaan. Di Hari 67, saya harus membangun ulang seluruh layer multi-tenancy ketika audit keamanan mengungkapkan kelemahan arsitektural. Lalu datang 31 blank screen dari konteks navigasi yang hilang, dan penemuan bahwa database saya secara teknis benar tapi 296x terlalu lambat.

---

Membangun SaaS multi-tenant? Arsitektur STRAŦUM mendukung pelanggan SME dan Agensi dari Hari 1. Minta akses alpha di https://stratum.chandlernguyen.com/request-invitation

---

Masih belajar bahwa keputusan arsitektur adalah keputusan bisnis yang menyamar. Masih debugging RLS policies. Masih mempertanyakan pilihan Hari 2 saya (tapi berkurang sekarang). Lebih banyak petualangan membangun di https://www.chandlernguyen.com/.

---