Cara Membuat PRD Aplikasi Web SaaS: 3 Keputusan yang Mahal Kalau Salah

Ada pelanggan yang japri lewat email: "kok di dashboard saya kelihatan ada project dari perusahaan lain?" Tim engineering telusuri punya telusuri, ternyata ada satu query di fitur laporan yang lupa difilter berdasarkan perusahaan mana yang sedang login. Fitur itu sudah dipakai berbulan-bulan sebelum ada yang sadar, karena secara tampilan semuanya kelihatan normal, cuma datanya yang diam-diam bocor.

Ini kelas bug yang lahir bukan dari coding yang ceroboh, tapi dari PRD yang tidak mengunci satu keputusan sejak hari pertama: bagaimana data tiap pelanggan dipisahkan. SaaS berdiri di atas tiga keputusan yang sama-sama mahal kalau salah di awal dan susah diubah belakangan - tenancy, autentikasi dan peran, serta batas paket. Ketiganya menyentuh hampir semua bagian aplikasi, jadi memperbaikinya setelah rilis berarti menyentuh ulang kode yang sama di puluhan tempat.

Tenancy: siapa boleh lihat data siapa

Multi-tenant artinya satu aplikasi melayani banyak pelanggan atau organisasi sekaligus, dan data mereka harus terisolasi dengan benar, pelanggan A tidak boleh dalam kondisi apa pun bisa mengakses data pelanggan B. PRD yang baik mengunci ini sejak awal dengan aturan konkret: setiap baris data punya kolom organizationId, dan semua query wajib difilter berdasarkan kolom itu, tanpa kecuali.

// tabel yang menyimpan data milik satu organisasi
users (id, organization_id, name, email, role)
projects (id, organization_id, name, created_at)

// setiap query WAJIB ikut memfilter ini:
SELECT * FROM projects WHERE organization_id = :currentOrgId

Menuliskan aturan ini secara eksplisit di PRD penting supaya agent AI tidak lupa menambahkan filter itu di fitur baru yang dibuat belakangan. Kalau perlu, sebutkan juga bahwa aturan ini berlaku di level query, bukan cuma di level tampilan, karena data yang cuma "disembunyikan" di UI tapi masih bisa diakses lewat API tetap terhitung bocor.

Uji isolasinya, jangan cuma percaya kodenya benar

Cara paling meyakinkan untuk tahu tenancy-mu benar bukan dengan membaca kode, tapi dengan mencobanya: login sebagai pengguna organisasi A, lalu coba akses data organisasi B lewat URL atau panggilan API langsung, bukan lewat menu. Kalau berhasil diakses, berarti ada query yang lupa difilter. Tuliskan pengecekan ini sebagai salah satu acceptance criteria di PRD, supaya ini jelas bukan langkah opsional.

Titik yang sering kelupaan bukan cuma endpoint yang diakses langsung dari browser, tapi juga proses di belakang layar: cron job yang mengirim laporan mingguan, fitur ekspor ke Excel, atau webhook ke sistem lain. Kalau bagian-bagian itu ditulis belakangan tanpa mengingat aturan organizationId, di situlah kebocoran biasanya lolos dari review.

Kalau tenancy ini baru dipikirkan setelah aplikasi jalan dengan puluhan tabel dan ratusan query, memperbaikinya berarti menelusuri satu per satu query itu untuk memastikan semuanya memfilter organization_id dengan benar - pekerjaan yang jauh lebih mahal dibanding menuliskan aturannya sejak baris kode pertama.

Autentikasi dan peran: siapa admin, siapa user biasa

Keputusan kedua adalah siapa yang boleh melakukan apa di dalam satu organisasi yang sama. Ini beda dari tenancy, tenancy soal batas antar-organisasi, sementara peran soal batas di dalam satu organisasi yang sama. PRD-mu perlu daftar peran yang eksplisit, dan untuk setiap fitur, siapa saja yang boleh mengaksesnya, jangan diserahkan ke asumsi agent, karena tebakannya soal siapa "pantas" jadi admin sering meleset.

• Owner - satu-satunya yang bisa mengubah billing dan menghapus organisasi
• Admin - mengelola anggota tim dan pengaturan, tapi tidak menyentuh billing
• Member - memakai fitur inti aplikasi sesuai pekerjaannya sehari-hari
• Viewer, kalau ada - hanya bisa melihat, tidak bisa mengubah apa pun

Kalau PRD-mu cuma menyebut "ada user biasa dan admin" tanpa merinci lebih jauh, agent akan membuat asumsi sendiri soal siapa boleh apa begitu fitur baru ditambahkan - dan asumsi itu jarang konsisten dari satu fitur ke fitur lain.

Kunci per fitur, bukan cuma per peran

Daftar peran saja belum cukup kalau tidak dipasangkan ke daftar fitur. Untuk aplikasi dengan belasan fitur, cara paling aman adalah membuat matriks: satu sisi daftar fitur seperti undang anggota, hapus project, lihat billing, atau ekspor data, sisi lain daftar peran, dan tiap selnya diisi eksplisit boleh atau tidak. PRD yang cuma bilang "admin bisa mengelola semuanya" meninggalkan terlalu banyak ruang tebak untuk fitur-fitur yang ditambahkan belakangan.

Batas paket: apa yang teknis beda tiap harga

Keputusan ketiga adalah apa yang sebenarnya membedakan tiap tingkatan harga secara teknis, bukan cuma secara marketing. "Paket Pro lebih lengkap" bukan spesifikasi yang bisa dikerjakan agent. PRD perlu angka dan aturan yang jelas, misalnya:

• Paket Starter - maksimal 3 pengguna dan 1 project aktif
• Paket Team - maksimal 20 pengguna dan 10 project aktif, fitur ekspor data mulai terbuka
• Paket Business - pengguna dan project tanpa batas, ditambah akses API

Sebagian batas cocok jadi hard limit yang tidak bisa dilanggar sama sekali, seperti jumlah pengguna. Sebagian lain lebih cocok jadi soft limit dengan peringatan, seperti kuota penyimpanan yang boleh sedikit terlampaui sebelum benar-benar diblokir. PRD perlu menyebutkan mana yang mana, karena keduanya butuh penanganan teknis yang berbeda di sisi agent.

Yang tidak kalah penting: apa yang terjadi ketika pelanggan menyentuh batas itu. Apakah aksinya langsung diblokir dengan pesan upgrade, atau tetap jalan dengan batasan tertentu, atau ada masa tenggang dulu sebelum benar-benar diblokir? Ini keputusan produk yang harus ada di PRD, bukan diserahkan ke agent untuk memutuskan sendiri saat menemui kasus itu di tengah coding.

Checklist singkat sebelum PRD SaaS-mu dianggap selesai

1. Setiap tabel data utama punya kolom organization_id, dan semua query wajib memfilternya, termasuk cron job dan ekspor data
2. Daftar peran dan matriks akses per fitur sudah eksplisit, bukan diasumsikan agent akan menebak dengan benar
3. Batas tiap paket berupa angka konkret, plus perilaku yang jelas saat batas itu tersentuh

Skema data yang menopang ketiga keputusan ini juga sebaiknya dirancang sejak di PRD, bukan di tengah proses coding - ada bahasannya lebih dalam di cara membuat skema database dari PRD.