Skema database rencana dan entitlements untuk upgrade dan add-on

Mengapa rencana dan fitur cepat berantakan

Rencana terlihat sederhana di halaman harga: Basic, Pro, Enterprise. Kekacauan muncul saat Anda mencoba mengubah nama-nama itu menjadi aturan akses nyata di dalam aplikasi.

Hardcode pengecekan fitur (seperti if plan = Pro then allow X) bekerja untuk versi pertama. Lalu harga berubah. Sebuah fitur dipindahkan dari Pro ke Basic, muncul add-on baru, atau ada kesepakatan penjualan yang memasukkan bundle kustom. Tiba-tiba Anda memiliki aturan yang sama disalin di API, UI, aplikasi mobile, dan job background. Anda mengubah satu tempat dan lupa yang lain. Pengguna menyadarinya.

Masalah kedua adalah waktu. Subscription bukan label statis; mereka berubah di tengah siklus. Seseorang upgrade hari ini, downgrade bulan depan, pause, atau batal dengan sisa waktu berbayar. Jika database Anda hanya menyimpan “plan saat ini”, Anda kehilangan timeline dan tidak bisa menjawab pertanyaan dasar nanti: Apa yang mereka akses Selasa lalu? Kenapa support menyetujui refund?

Add-on membuatnya lebih buruk karena melintasi plan. Add-on mungkin membuka kursi ekstra, menghapus batas, atau mengaktifkan fitur tertentu. Orang bisa membelinya pada plan mana saja, mencopotnya nanti, atau menyimpannya setelah downgrade. Jika aturan tertanam di kode, Anda berakhir dengan tumpukan kasus khusus yang semakin banyak.

Berikut situasi yang biasanya merusak desain naif:

• Upgrade mid-cycle: akses harus berubah segera, proration billing mungkin mengikuti aturan berbeda.
• Downgrade terjadwal: akses mungkin tetap “lebih tinggi” sampai periode berbayar berakhir.
• Grandfathering: pelanggan lama tetap mendapatkan fitur yang pelanggan baru tidak dapatkan.
• Kesepakatan kustom: satu akun mendapat Fitur A tapi bukan Fitur B, meskipun berbagi nama plan yang sama.
• Kebutuhan audit: support, finance, atau compliance menanyakan “apa yang tepatnya diaktifkan dan kapan?”

Tujuannya sederhana: model kontrol akses yang fleksibel yang berubah seiring harga, tanpa menulis ulang logika bisnis setiap kali. Anda ingin satu tempat untuk bertanya “bolehkah mereka melakukan ini?” dan jejak database yang menjelaskan jawabannya.

Di akhir artikel ini, Anda akan punya pola skema yang bisa disalin: plan dan add-on menjadi input, dan entitlements menjadi sumber kebenaran tunggal untuk akses fitur. Pendekatan yang sama juga cocok untuk builder no-code seperti AppMaster, karena Anda bisa menyimpan aturan dalam data dan menanyakannya secara konsisten dari backend, web app, dan mobile app.

Istilah kunci: plan, add-on, entitlement, dan access

Banyak masalah subscription bermula dari masalah kosakata. Jika setiap orang memakai kata yang sama untuk hal berbeda, skema Anda berubah jadi kumpulan kasus khusus.

Berikut istilah yang sebaiknya dibedakan dalam skema database rencana dan entitlements:

• Plan: Bundel default yang didapat seseorang saat berlangganan (misalnya Basic atau Pro). Plan biasanya menetapkan batas dasar dan fitur yang disertakan.
• Add-on: Pembelian opsional yang mengubah baseline (misalnya “extra seats” atau “advanced reporting”). Add-on harus bisa dipasang dan dicopot tanpa mengubah plan.
• Entitlement: Hasil akhir yang dihitung “apa yang mereka miliki saat ini,” setelah menggabungkan plan + add-on + override. Inilah yang harus ditanyakan aplikasi Anda.
• Permission (atau capability): Tindakan spesifik yang bisa dilakukan seseorang (misalnya “export data” atau “manage billing”). Permission sering bergantung pada peran plus entitlements.
• Access: Hasil nyata saat aplikasi menegakkan aturan (layar menampilkan atau menyembunyikan fitur, panggilan API diizinkan atau diblokir, batas diterapkan).

Feature flag terkait tapi berbeda. Sebuah feature flag biasanya saklar produk yang Anda kendalikan (rollout, eksperimen, mematikan fitur saat insiden). Sebuah entitlement adalah akses spesifik pelanggan berdasarkan apa yang mereka bayar atau apa yang Anda berikan. Gunakan flag ketika Anda ingin mengubah perilaku untuk kelompok tanpa menyentuh billing. Gunakan entitlements ketika akses harus cocok dengan subscription, invoice, atau kontrak.

Ruang lingkup juga sumber kebingungan lain. Jaga istilah ini jelas:

• User: Satu orang. Cocok untuk peran (admin vs member) dan batas personal.
• Account (customer): Entitas yang membayar. Cocok untuk info billing dan kepemilikan subscription.
• Workspace (project/team): Tempat kerja berlangsung. Banyak produk menerapkan entitlements di sini (seats, storage, modul yang diaktifkan).

Waktu penting karena akses berubah. Modelkan langsung:

• Start and end: Entitlement bisa aktif hanya dalam jendela waktu (trial, promo, kontrak tahunan).
• Scheduled change: Upgrade bisa mulai sekarang; downgrade sering mulai pada pembaruan berikutnya.
• Grace and cancelation: Anda mungkin mengizinkan akses terbatas setelah pembayaran gagal, tapi hanya sampai tanggal akhir yang jelas.

Contoh: Sebuah perusahaan berada di Pro, menambahkan “Advanced Reporting” di pertengahan bulan, lalu menjadwalkan downgrade ke Basic pada siklus berikutnya. Plan berubah kemudian, add-on mulai sekarang, dan lapisan entitlement tetap menjadi tempat tunggal untuk menanyakan: “Bisa workspace ini menggunakan advanced reports hari ini?”

Skema inti sederhana untuk rencana dan fitur

Skema database rencana dan entitlements yang baik dimulai kecil: pisahkan apa yang Anda jual (plan dan add-on) dari apa yang orang bisa lakukan (fitur). Jika Anda menjaga dua ide itu bersih, upgrade dan add-on baru menjadi perubahan data, bukan rewrite.

Berikut set tabel inti praktis yang bekerja untuk sebagian besar produk subscription:

• products: barang yang dijual (Base plan, Team plan, Extra seats add-on, Priority support add-on).
• plans: opsional, jika Anda ingin plan menjadi tipe khusus dari product dengan field khusus plan (interval billing, urutan tampilan publik). Banyak tim cukup menyimpan plan di dalam products dan menggunakan kolom product_type.
• features: katalog kemampuan (API access, max projects, export, SSO, SMS credits).
• product_features (atau plan_features jika Anda memisah plan): tabel penggabung yang menyatakan fitur mana yang masuk ke product tertentu, biasanya dengan suatu nilai.

Tabel penggabung itulah tempat sebagian besar kekuatan berada. Fitur jarang hanya on/off. Sebuah plan mungkin menyertakan max_projects = 10, sementara add-on mungkin menambah +5. Jadi product_features harus mendukung setidaknya:

• feature_value (angka, teks, JSON, atau kolom terpisah)
• value_type (boolean, integer, enum, json)
• grant_mode (replace vs add), sehingga add-on bisa “add 5 seats” alih-alih menimpa batas dasar

Modelkan add-on juga sebagai produk. Satu-satunya perbedaan adalah cara mereka dibeli. Produk plan dasar umumnya “satu saja”, sedangkan produk add-on mungkin mengizinkan quantity. Tapi keduanya dipetakan ke fitur dengan cara yang sama. Ini menghindari kasus khusus seperti “jika add-on X maka aktifkan fitur Y” yang tersebar di kode.

Fitur harus berupa data, bukan konstanta kode. Jika Anda meng-hardcode pengecekan fitur di banyak layanan, pada akhirnya Anda akan mengirimkan mismatch (web bilang ya, mobile bilang tidak, backend berbeda). Saat fitur hidup di database, aplikasi dapat menanyakan satu pertanyaan konsisten dan Anda bisa merilis perubahan dengan mengedit baris.

Penamaan lebih penting dari yang diduga. Gunakan pengenal stabil yang tidak pernah berubah, bahkan jika nama marketing berubah:

• feature_key seperti max_projects, sso, priority_support
• product_code seperti plan_starter_monthly, addon_extra_seats

Pisahkan label tampilan (feature_name, product_name). Jika Anda menggunakan AppMaster’s Data Designer dengan PostgreSQL, memperlakukan key ini sebagai field unik langsung terasa manfaatnya: Anda bisa meregenerasi dengan aman sambil menjaga integrasi dan pelaporan tetap stabil.

Lapisan entitlement: satu tempat untuk bertanya “bolehkah mereka?”

Kebanyakan sistem subscription melenceng ketika “apa yang mereka beli” disimpan di satu tempat, tetapi “apa yang mereka bisa lakukan” dihitung di lima jalur kode berbeda. Perbaikannya adalah lapisan entitlement: satu tabel (atau view) yang mewakili akses efektif untuk subjek pada titik waktu tertentu.

Jika Anda mengincar skema database rencana dan entitlements yang tahan terhadap upgrade, downgrade, trial, dan pemberian satu kali, lapisan ini adalah bagian yang membuat semuanya dapat diprediksi.

Tabel entitlements praktis

Anggap setiap baris sebagai satu klaim: “subjek ini memiliki akses ke fitur ini dengan nilai ini, dari waktu ini sampai waktu itu, dari sumber ini.” Bentuk umum terlihat seperti ini:

• subject_type (mis. "account", "user", "org") dan subject_id
• feature_id
• value (nilai efektif untuk fitur itu)
• source (darimana datang: "direct", "plan", "addon", "default")
• starts_at dan ends_at (ends_at nullable untuk akses yang berkelanjutan)

Anda dapat mengimplementasikan value dengan beberapa cara: satu kolom text/JSON plus value_type, atau kolom terpisah seperti value_bool, value_int, value_text. Jaga agar biasa dan mudah di-query.

Tipe nilai yang menutup sebagian besar kebutuhan produk

Fitur tidak selalu on/off. Tipe nilai ini biasanya memenuhi kebutuhan kontrol akses dan billing:

• Boolean: enabled/disabled ("can_export" = true)
• Quota number: batas ("seats" = 10, "api_calls" = 100000)
• Tier level: peringkat ("support_tier" = 2)
• String: mode atau varian ("data_retention" = "90_days")

Precedence: bagaimana konflik diselesaikan

Konflik adalah normal. Seseorang mungkin berada di plan yang memberi 5 seats, membeli add-on untuk menambah 10 lagi, dan juga mendapat grant manual dari support.

Tetapkan aturan yang jelas dan patuhi di mana-mana:

1. Direct grant mengalahkan plan
2. Kemudian add-ons
3. Kemudian defaults

Pendekatan sederhana adalah menyimpan semua baris kandidat (derived dari plan, derived dari add-on, direct) dan menghitung “pemenang” akhir per subject_id + feature_id dengan mengurutkan berdasarkan precedence sumber, lalu starts_at terbaru.

Berikut skenario konkret: pelanggan men-downgrade plan hari ini, tapi mereka sudah membayar add-on yang berlaku sampai akhir bulan. Dengan starts_at/ends_at pada entitlements, downgrade berlaku segera untuk fitur berbasis plan, sementara fitur dari add-on tetap aktif sampai ends_at-nya. Aplikasi Anda bisa menjawab “bolehkah mereka?” dengan satu query alih-alih logika kasus khusus.

Subscription, item, dan akses berbatas waktu

Katalog plan Anda (plan, add-on, fitur) adalah “apa”. Subscription adalah “siapa punya apa, dan kapan”. Jika Anda memisahkannya, upgrade dan cancellation berhenti menakutkan.

Pola praktis: satu subscription per akun, dan banyak subscription items di bawahnya (satu untuk plan dasar, plus nol atau lebih add-on). Dalam skema rencana dan entitlements, ini memberi tempat bersih untuk mencatat perubahan dari waktu ke waktu tanpa menulis ulang aturan akses.

Tabel inti untuk memodelkan timeline pembelian

Anda bisa menyederhanakannya dengan dua tabel yang mudah di-query:

• subscriptions: id, account_id, status (active, trialing, canceled, past_due), started_at, current_period_start, current_period_end, canceled_at (nullable)
• subscription_items: id, subscription_id, item_type (plan, addon), plan_id/addon_id, quantity, started_at, ends_at (nullable), source (stripe, manual, promo)

Detail umum: simpan setiap item dengan tanggalnya sendiri. Dengan begitu Anda bisa memberikan add-on hanya selama 30 hari, atau membiarkan plan berjalan sampai akhir periode berbayar meski pelanggan membatalkan renewal.

Jaga proration dan billing di luar logika akses

Proration, invoice, dan payment retry adalah masalah billing. Akses fitur adalah masalah entitlement. Jangan mencoba “menghitung akses” dari baris invoice.

Sebaliknya, biarkan event billing memperbarui record subscription (mis. memperpanjang current_period_end, membuat baris subscription_item baru, atau mengatur ends_at). Aplikasi Anda lalu menjawab pertanyaan akses dari timeline subscription (dan kemudian dari lapisan entitlement), bukan dari matematika billing.

Perubahan terjadwal tanpa kejutan

Upgrade dan downgrade sering berlaku pada momen tertentu:

• Tambahkan pending_plan_id dan change_at pada subscriptions untuk satu perubahan plan terjadwal.
• Atau gunakan tabel subscription_changes (subscription_id, effective_at, from_plan_id, to_plan_id, reason) jika Anda butuh riwayat dan beberapa perubahan di masa depan.

Ini mencegah pengodean aturan seperti “downgrade terjadi di akhir periode” di bagian acak kode Anda. Jadwal adalah data.

Di mana trial masuk

Trial hanyalah akses berbatas waktu dengan sumber yang berbeda. Dua opsi bersih:

• Perlakukan trial sebagai status subscription (trialing) dengan trial_start/trial_end.
• Atau buat item/grant entitlements trial dengan started_at/ends_at dan source = trial.

Jika Anda membangun ini di AppMaster, tabel-tabel ini terpetakan rapi ke Data Designer di PostgreSQL, dan tanggal membuat mudah untuk menanyakan “apa yang aktif sekarang” tanpa kasus khusus.

Langkah demi langkah: implementasikan pola

Skema rencana dan entitlements yang baik dimulai dengan satu janji: logika fitur hidup di data, bukan tersebar di jalur kode. Aplikasi Anda harus menanyakan satu pertanyaan - “apa entitlements efektif sekarang?” - dan mendapatkan jawaban yang jelas.

1) Definisikan fitur dengan kunci stabil

Buat tabel feature dengan kunci yang stabil dan mudah dibaca yang tidak akan Anda ubah (meskipun label UI berubah). Kunci yang baik terlihat seperti export_csv, api_calls_per_month, atau seats.

Tambahkan tipe agar sistem tahu bagaimana memperlakukan nilai: boolean (on/off) vs numeric (limit/kuota). Jaga agar biasa dan konsisten.

2) Pemetaan plan dan add-on ke entitlements

Sekarang Anda butuh dua sumber kebenaran: apa yang disertakan sebuah plan, dan apa yang diberikan masing-masing add-on.

Urutan sederhana dan praktis:

• Masukkan semua fitur di satu tabel feature dengan kunci stabil dan tipe nilai.
• Buat plan dan plan_entitlement di mana setiap baris memberi nilai fitur (mis. seats = 5, export_csv = true).
• Buat addon dan addon_entitlement yang memberi nilai ekstra (mis. seats + 10, api_calls_per_month + 50000, atau priority_support = true).
• Putuskan cara menggabungkan nilai: boolean biasanya menggunakan OR, batas numerik sering menggunakan MAX (nilai lebih tinggi menang), dan kuantitas kursi sering menggunakan SUM.
• Catat kapan entitlements mulai dan berakhir sehingga upgrade, cancellation, dan proration tidak merusak pengecekan akses.

Jika Anda membangun ini di AppMaster, Anda bisa memodelkan tabel-tabel ini di Data Designer dan menjaga aturan penggabungan sebagai tabel kecil "policy" atau enum yang dipakai oleh Business Process Anda.

3) Hasilkan “entitlements efektif”

Anda punya dua opsi: compute on read (query dan gabungkan setiap kali) atau menghasilkan snapshot yang di-cache saat sesuatu berubah (perubahan plan, pembelian add-on, renewal, cancel). Untuk kebanyakan aplikasi, snapshot lebih mudah ditelaah dan lebih cepat di bawah beban.

Pendekatan umum adalah tabel account_entitlement yang menyimpan hasil akhir per fitur, plus valid_from dan valid_to.

4) Tegakkan akses dengan satu pemeriksaan

Jangan sebarkan aturan ke layar, endpoint, dan job background. Letakkan satu fungsi di kode aplikasi yang membaca entitlements efektif dan memutuskan.

can(account_id, feature_key, needed_value=1):
  ent = get_effective_entitlement(account_id, feature_key, now)
  if ent.type == "bool": return ent.value == true
  if ent.type == "number": return ent.value >= needed_value

Setelah semua memanggil can(...), upgrade dan add-on menjadi pembaruan data, bukan rewrite.

Contoh skenario: upgrade plus add-on tanpa kejutan

Tim support beranggotakan 6 orang ada di Starter plan. Starter menyertakan 3 kursi agent dan 1.000 SMS per bulan. Di tengah bulan mereka berkembang menjadi 6 agent dan menginginkan paket SMS tambahan 5.000. Anda ingin ini bekerja tanpa kode kasus khusus seperti “jika plan = Pro maka…”.

Hari 1: mereka mulai di Starter

Anda membuat subscription untuk akun dengan periode billing (mis. 1 Jan sampai 31 Jan). Lalu Anda tambahkan satu subscription_item untuk plan.

Di checkout (atau lewat job malam), Anda menulis grant entitlement untuk periode itu:

• entitlement_grant: agent_seats, value 3, start Jan 1, end Jan 31
• entitlement_grant: sms_messages, value 1000, start Jan 1, end Jan 31

Aplikasi Anda tidak pernah bertanya “mereka di plan apa?” Melainkan “apa entitlements efektif mereka sekarang?” dan mendapatkan seats = 3, SMS = 1000.

Hari 15: upgrade ke Pro, sekaligus tambah paket SMS

Pada 15 Jan mereka upgrade ke Pro (termasuk 10 seats agent dan 2.000 SMS). Anda tidak mengedit grant lama. Anda menambahkan record baru:

• Tutup item plan lama: set subscription_item (Starter) end ke Jan 15
• Buat item plan baru: subscription_item (Pro) start Jan 15, end Jan 31
• Tambah item add-on: subscription_item (SMS Pack 5000) start Jan 15, end Jan 31

Lalu grant untuk periode yang sama ditambahkan:

• entitlement_grant: agent_seats, value 10, start Jan 15, end Jan 31
• entitlement_grant: sms_messages, value 2000, start Jan 15, end Jan 31
• entitlement_grant: sms_messages, value 5000, start Jan 15, end Jan 31

Apa yang terjadi segera pada 15 Jan?

• Seats: seats efektif menjadi 10 (Anda memilih aturan seperti “ambil max untuk seats”). Mereka bisa menambahkan 3 agent lagi hari itu.
• SMS: SMS efektif menjadi 7.000 untuk sisa periode (Anda memilih “jumlahkan grant tambahan” untuk paket pesan).

Tidak ada penggunaan yang perlu “dipindah.” Tabel usage Anda terus menghitung pesan terkirim; pengecekan entitlement cukup membandingkan penggunaan periode ini terhadap batas efektif saat ini.

Hari 25: jadwalkan downgrade, tetap akses sampai akhir periode

Pada 25 Jan mereka menjadwalkan downgrade kembali ke Starter mulai 1 Feb. Anda tidak menyentuh grant Jan. Anda membuat item masa depan (atau grant masa depan) untuk periode berikutnya:

• subscription_item (Starter) start Feb 1, end Feb 28
• Tidak ada item paket SMS mulai Feb 1

Hasil: mereka mempertahankan seats Pro dan paket SMS sampai 31 Jan. Pada 1 Feb, seats efektif turun menjadi 3 dan SMS kembali ke batas Starter untuk periode baru. Ini mudah dipahami, dan cocok dengan alur no-code di AppMaster: mengubah tanggal membuat baris baru, dan query entitlement tetap sama.

Kesalahan umum dan jebakan

Sebagian besar bug subscription bukan bug billing. Mereka adalah bug akses yang disebabkan logika tersebar di produk. Cara tercepat merusak skema rencana dan entitlements adalah menjawab “bolehkah mereka menggunakan ini?” di lima tempat berbeda.

Kegagalan klasik adalah meng-hardcode aturan di UI, API, dan job background secara terpisah. UI menyembunyikan tombol, API lupa memblokir endpoint, dan job malam masih berjalan karena memeriksa hal lain. Anda berakhir dengan laporan “kadang berfungsi” yang sulit direproduksi.

Jebakan lain adalah menggunakan pengecekan plan_id alih-alih pengecekan fitur. Rasanya sederhana pada awalnya (Plan A bisa export, Plan B tidak), tapi runtuh begitu Anda menambahkan add-on, pelanggan grandfathered, trial gratis, atau pengecualian enterprise. Jika Anda pernah berkata “if plan is Pro then allow…”, Anda sedang membangun labirin yang harus Anda pelihara selamanya.

Kasus tepi waktu dan pembatalan

Akses juga bisa “terkunci” ketika Anda hanya menyimpan boolean seperti has_export = true dan tidak pernah menambahkan tanggal. Pembatalan, refund, chargeback, dan downgrade mid-cycle semua butuh batas waktu. Tanpa starts_at dan ends_at, Anda akan tanpa sengaja memberi akses permanen, atau mencabut akses terlalu awal.

Cek sederhana untuk menghindari ini:

• Setiap entitlement grant harus punya sumber (plan, add-on, override manual) dan rentang waktu.
• Setiap keputusan akses harus menggunakan “now antara start dan end” (dengan aturan jelas untuk end null).
• Job background harus memeriksa ulang entitlements pada waktu jalan, bukan mengasumsikan kondisi kemarin.

Jangan campur billing dan akses

Tim juga bermasalah saat mencampur record billing dan aturan akses di tabel yang sama. Billing butuh invoice, pajak, proration, provider ID, dan status retry. Akses butuh key fitur jelas dan jendela waktu. Ketika keduanya kusut, migrasi billing bisa jadi outage produk.

Terakhir, banyak sistem melewatkan jejak audit. Ketika pengguna bertanya “kenapa saya bisa export?”, Anda perlu jawaban seperti: “Diaktifkan oleh Add-on X dari 2026-01-01 sampai 2026-02-01” atau “Diberikan manual oleh support, tiket 1842.” Tanpa itu, support dan engineering hanya menebak.

Jika Anda membangun ini di AppMaster, simpan field audit di Data Designer dan buat pengecekan “bolehkah mereka?” sebagai satu Business Process yang dipakai oleh web, mobile, dan flow terjadwal.

Daftar periksa cepat sebelum rilis

Sebelum Anda rilis skema rencana dan entitlements, lakukan satu pemeriksaan terakhir dengan pertanyaan nyata, bukan teori. Tujuannya agar akses bisa dijelaskan, diuji, dan mudah diubah.

Pertanyaan pemeriksaan realitas

Pilih satu pengguna dan satu fitur, lalu coba jelaskan hasilnya seperti Anda menjelaskannya ke support atau finance. Jika Anda hanya bisa menjawab “mereka di Pro” (atau lebih buruk, “kodenya bilang begitu”), Anda akan merasakan sakit saat seseorang upgrade mid-cycle atau mendapat kesepakatan satu kali.

Gunakan daftar periksa ini:

• Bisakah Anda menjawab “kenapa pengguna ini punya akses?” hanya dengan data (subscription items, add-ons, override, dan jendela waktu), tanpa membaca kode aplikasi.
• Apakah semua pengecekan akses berbasis key fitur stabil (seperti feature.export_csv) bukan nama plan (seperti “Starter” atau “Business”). Nama plan berubah; feature key tidak boleh.
• Apakah entitlements punya waktu mulai dan akhir yang jelas, termasuk trial, grace period, dan pembatalan terjadwal. Jika waktu hilang, downgrade jadi sumber argumen.
• Bisakah Anda memberi atau mencabut akses untuk satu pelanggan dengan record override, tanpa membelitkan logika Anda. Ini cara menangani “beri mereka 10 seats ekstra bulan ini” tanpa kode khusus.
• Bisakah Anda menguji upgrade dan downgrade dengan beberapa baris contoh dan mendapatkan hasil yang dapat diprediksi. Jika Anda butuh skrip kompleks untuk mensimulasinya, model Anda terlalu implisit.

Tes praktis: buat tiga pengguna (baru, upgrade mid-month, batal) dan satu add-on (seperti “extra seats” atau “advanced reports”). Jalankan query akses untuk masing-masing. Jika hasilnya jelas dan bisa dijelaskan, Anda siap.

Jika Anda menggunakan tool seperti AppMaster, tetap pegang aturan yang sama: buat satu tempat (satu query atau satu Business Process) yang bertanggung jawab atas “bolehkah mereka?” sehingga setiap layar web dan mobile memakai jawaban yang sama.

Langkah selanjutnya: buat upgrade mudah dipelihara

Cara terbaik menjaga upgrade tetap rapi adalah mulai lebih kecil dari yang Anda kira. Pilih beberapa fitur yang benar-benar memberi nilai (5-10 sudah cukup) dan bangun satu query atau fungsi entitlement yang menjawab satu pertanyaan: “Bisa akun ini melakukan X sekarang?” Jika Anda tidak bisa menjawab itu di satu tempat, upgrade akan selalu terasa berisiko.

Setelah pemeriksaan itu bekerja, perlakukan jalur upgrade sebagai perilaku produk, bukan hanya perilaku billing. Cara tercepat menangkap kasus tepi aneh adalah menulis beberapa tes akses kecil berdasarkan perpindahan pelanggan nyata.

Berikut langkah praktis yang sering memberi hasil cepat:

• Definisikan katalog fitur minimal dan petakan setiap plan ke set entitlements yang jelas.
• Tambahkan add-on sebagai “item” terpisah yang memberi atau memperpanjang entitlements, alih-alih mem-bake mereka ke aturan plan.
• Tulis 5-10 tes akses untuk jalur umum (upgrade mid-cycle, downgrade saat renewal, add-on ditambah lalu dihapus, trial ke paid, grace period).
• Jadikan perubahan harga sebagai perubahan data: update baris plan, pemetaan fitur, dan grant entitlements, bukan kode aplikasi.
• Biasakan: setiap plan atau add-on baru harus disertai setidaknya satu tes yang membuktikan akses berperilaku seperti yang diharapkan.

Jika Anda memakai backend no-code, Anda tetap bisa memodelkan pola ini dengan rapi. Di AppMaster, Data Designer cocok untuk tabel inti (plans, features, subscriptions, subscription items, entitlements). Lalu Business Process Editor dapat menampung alur keputusan akses (load active entitlements, terapkan jendela waktu, kembalikan allow/deny) sehingga Anda tidak menulis pengecekan tersebar di endpoint.

Keuntungannya muncul di kali berikutnya harga berubah. Alih-alih menulis ulang aturan, Anda mengedit data: sebuah fitur dipindahkan dari “Pro” ke add-on, durasi entitlement berubah, atau plan legacy mempertahankan grant lama. Logika akses tetap stabil, dan upgrade menjadi pembaruan terkontrol, bukan sprint kode.

Jika Anda ingin memvalidasi skema dengan cepat, coba modelkan satu upgrade plus satu add-on secara end-to-end, lalu jalankan tes akses itu sebelum menambahkan apa pun lagi.