Langganan vs penagihan berbasis penggunaan: apa yang harus disimpan sejak hari pertama

Mengapa model harga butuh rencana data

Harga bukan sekadar halaman di situs Anda. Itu menentukan apa yang harus Anda catat, bagaimana Anda melaporkannya, dan apakah Anda bisa menjelaskan suatu biaya beberapa bulan kemudian. Saat Anda memilih langganan atau penagihan berbasis penggunaan, Anda juga memilih bentuk data penagihan Anda.

Langganan sederhana seringkali dapat dihitung dari beberapa fakta: paket, periode penagihan, tanggal mulai, dan diskon. Harga berbasis penggunaan butuh lebih banyak: apa yang digunakan, kapan terjadi, pelanggan mana yang memilikinya, dan bagaimana penggunaan itu berubah menjadi uang. Tanpa catatan tersebut, Anda masih bisa mengirim faktur, tetapi Anda tidak bisa mempertahankannya.

Menambahkan penggunaan nanti tanpa perencanaan biasanya rusak di tiga tempat:

• Anda kekurangan riwayat penggunaan yang dapat dipercaya, sehingga pelanggan mempersoalkan biaya.
• Analitik Anda menjadi tebak-tebakan karena tim mendefinisikan "penggunaan" secara berbeda.
• Keuangan tidak bisa mengaudit faktur karena input mentah hilang atau ditimpa.

Tujuannya membosankan tetapi penting: hitung faktur yang sama dengan cara yang sama setiap kali. Itu berarti Anda bisa memutar ulang kalkulasi dari fakta yang disimpan (ketentuan paket, aturan meter, event penggunaan, dan versi harga tepat yang berlaku).

"Pandangan pemodelan" hanya berarti menggambarkan penagihan sebagai blok bangunan yang saling cocok, bahkan jika Anda bukan insinyur. Bayangkan produk chat tim:

• Langganan: $99 per workspace per bulan
• Penggunaan: $0.01 per pesan setelah 50.000 pesan

Untuk mendukung itu nanti, data Anda harus menjawab: workspace mana, bulan mana, berapa banyak pesan, apa yang termasuk, dan aturan harga mana yang aktif.

Langganan vs penggunaan: bagaimana mereka berbeda dalam praktik

Langganan mengenakan biaya untuk akses. Penagihan berbasis penggunaan mengenakan biaya untuk konsumsi. Mereka berperilaku sangat berbeda ketika Anda memiliki upgrade, downgrade, prorata, dan kasus tepi dunia nyata.

Dengan langganan, pertanyaan kuncinya adalah: "Apakah pelanggan berhak menggunakan produk selama waktu ini?" Anda sebagian besar melacak paket, jumlah seat, periode penagihan, dan apakah faktur dibayar. Penggunaan masih penting, tetapi sering muncul sebagai batas (lunak atau keras) alih-alih baris item.

Dengan penagihan berbasis penggunaan, pertanyaan kuncinya menjadi: "Apa yang terjadi, tepatnya, dan kapan?" Anda perlu metering yang andal, aturan jelas kapan penggunaan dihitung, dan cara menjelaskan setiap biaya nanti. Bahkan jika UI Anda menampilkan satu angka (seperti "1,243 API calls"), di baliknya ada serangkaian event yang harus konsisten dan dapat diaudit.

Banyak tim B2B SaaS berakhir pada harga hybrid: biaya dasar yang mencakup bundel, plus biaya overage.

Pola hybrid umum

Sebagian besar model hybrid masuk dalam beberapa bentuk yang familiar:

• Biaya platform dasar ditambah biaya per seat
• Biaya dasar plus unit yang termasuk (pesan, tugas, panggilan API) plus tarif overage
• Paket bertingkat plus add-on penggunaan (dikenakan hanya saat diaktifkan)
• Komitmen minimum dengan penarikan kredit penggunaan

Keterdugaan membantu ketika pelanggan membutuhkan persetujuan anggaran dan pengeluaran bulanan yang stabil. Bayar sesuai pemakaian lebih cocok ketika nilai meningkat seiring aktivitas (misalnya, "per faktur yang diproses"), atau ketika pelanggan sedang mencoba layanan dan ingin risiko rendah.

Perubahan paket pasti akan terjadi. Harga, bundel, dan pengemasan akan bergeser. Desain penagihan sehingga Anda bisa menambahkan meter baru, memperkenalkan tier baru, atau mengubah apa yang dimaksud dengan "termasuk" tanpa menulis ulang sejarah. Aturan praktis: simpan paket pelanggan dan ketentuan harga seperti saat biaya terjadi, bukan hanya apa yang mereka miliki hari ini.

Definisikan meter yang bisa Anda ukur dengan andal

Meter adalah hal tepat yang Anda kenakan biaya, ditulis dengan sangat jelas sehingga dua orang yang menghitungnya akan mendapatkan angka yang sama. Ia memiliki tiga bagian: event (apa yang terjadi), unit (apa yang Anda hitung), dan waktu (kapan dihitung).

Sebagian besar sengketa dimulai di sini. Satu pihak berpikir mereka membayar untuk hasil, pihak lain mengenakan biaya untuk aktivitas yang terukur.

Buat meter tak ambigu

Pilih meter yang memetakan ke aksi produk nyata dan bisa direkam secara otomatis. Contoh umum:

• Seats (pengguna aktif yang bisa masuk)
• API calls (permintaan yang berhasil, atau semua permintaan)
• Storage (GB pada titik waktu tertentu, atau rata-rata selama periode)
• Pesan (terkirim, diterima, atau dibuka)
• Menit komputasi (waktu job berjalan)

Lalu definisikan apa yang dihitung dan apa yang tidak. Jika Anda menagih per API call, tentukan apakah retry dihitung, apakah response 4xx dan 5xx dihitung, dan apakah panggilan internal oleh integrasi Anda sendiri dihitung.

Waktu sama pentingnya dengan unit. Seats seringkali bekerja paling baik sebagai snapshot titik-waktu per periode penagihan. API calls biasanya dijumlahkan dalam jendela. Storage sulit: pelanggan berharap membayar untuk "berapa banyak yang Anda simpan," yang biasanya berarti rata-rata sepanjang waktu, bukan puncak.

Juga putuskan cakupan: per akun, atau per workspace/proyek. Aturan sederhana: jika tim bisa ditagih secara terpisah, meter harus per workspace.

Batas, tier, dan entitlements

Entitlements adalah aturan untuk apa yang pelanggan diperbolehkan lakukan karena apa yang mereka beli. Mereka menjawab pertanyaan seperti: Berapa banyak pengguna yang bisa mereka tambahkan? Fitur mana yang diaktifkan? Volume berapa yang diizinkan per bulan? Entitlements berada di antara akses dan penagihan: mereka membentuk apa yang produk izinkan, sementara metering merekam apa yang sebenarnya terjadi.

Jaga entitlements terpisah dari logika metering. Entitlements harus dapat dibaca dan stabil (paket, add-on, ketentuan kontrak). Metering akan berevolusi seiring produk berkembang (event baru, meter baru), dan Anda tidak ingin setiap perubahan meter membahayakan akses.

Batas keras, batas lunak, dan penagihan overage bisa terlihat serupa di UI, tetapi berperilaku sangat berbeda:

• Batas keras memblokir aksi setelah batas tercapai.
• Batas lunak membiarkan aksi tetapi memberi peringatan dan memberi tanda untuk tindak lanjut.
• Penagihan overage membiarkan aksi dan mengenakan biaya untuk penggunaan ekstra.
• Periode tenggang memperlakukan batas keras seperti batas lunak untuk sementara.
• Trial dan tier gratis menerapkan entitlements, tetapi harganya berbeda (sering nol) sampai tanggal atau ambang tertentu.

Putuskan sebelumnya apa yang terjadi ketika batas terlampaui. Contoh: tim di tier "Starter" termasuk 5 seat dan 10.000 API calls per bulan. Jika mereka mengundang pengguna ke-6, apakah Anda memblokirnya, mulai menagih per seat ekstra, atau mengizinkan selama 7 hari sebagai masa tenggang? Setiap pilihan membutuhkan aturan yang bisa Anda tunjukkan di faktur dan di log dukungan.

Simpan entitlements sebagai catatan berbatas waktu: pelanggan, paket atau add-on, timestamp mulai dan berakhir, nilai batas, dan mode penegakan (keras, lunak, overage). Ini menjaga keputusan akses dan penagihan konsisten.

Faktur dan periode penagihan yang bisa diaudit

Faktur bukan sekadar PDF. Itu adalah jejak audit yang menjawab: siapa yang ditagih, untuk apa, untuk tanggal mana, di bawah aturan mana. Jika Anda mengubah harga, Anda harus tetap bisa membangun kembali faktur lama persis seperti semula.

Mulailah dengan beberapa catatan inti: Customer, Subscription (atau Kontrak), Billing Period, dan Invoice dengan Line Items. Setiap baris harus menunjuk kembali ke sumbernya: biaya paket, ringkasan penggunaan, atau biaya sekali bayar. Tautan itu yang membuat penagihan dapat dijelaskan ketika seseorang mempersoalkan biaya.

Periode penagihan butuh anchor dan zona waktu. "Bulanan" tidak cukup. Simpan cycle anchor date (misal, tanggal 15 pada 00:00) dan zona waktu yang digunakan untuk memotong periode. Jaga ini konsisten atau Anda akan mendapatkan masalah selisih satu hari sekitar daylight saving time.

Faktur yang dapat diaudit biasanya memerlukan:

• period_start dan period_end pada setiap faktur dan baris faktur
• Versi harga (plan/price IDs) yang digunakan untuk faktur itu
• Total yang immutable: subtotal, pajak, diskon, amount_due, mata uang
• Jendela penggunaan tepat untuk setiap baris faktur berbasis penggunaan
• Referensi pembayaran eksternal (ID charge processor) bila berlaku

Pengakuan pendapatan terkait tetapi tidak sama dengan penagihan. Biaya langganan prabayar biasanya diakui sepanjang periode layanan, sementara penggunaan sering diakui saat diserahkan. Bahkan jika Anda mempertahankannya dalam tingkat tinggi, simpan cukup tanggal untuk mendukungnya nanti.

Perlakukan nota kredit, pengembalian dana, dan penyesuaian sebagai catatan kelas-satu, bukan sebagai edit pada faktur lama. Jika pelanggan upgrade di tengah siklus, buat baris penyesuaian atau nota kredit yang merujuk faktur asli dan menyatakan aturan prorata yang digunakan.

Kunci idempoten penting untuk pembuatan faktur dan upaya pembayaran. Jika sebuah job berjalan dua kali, Anda ingin satu faktur, satu charge, dan log yang jelas.

Prorata dan perubahan di tengah siklus

Perubahan di tengah siklus adalah tempat argumen penagihan dimulai. Jika seseorang upgrade pada tanggal 20, jeda seminggu, lalu batal, Anda perlu aturan yang mengubah aksi itu menjadi angka yang masuk akal pada faktur.

Putuskan perubahan apa yang Anda izinkan dan kapan mereka berlaku. Banyak tim menerapkan upgrade segera sehingga pelanggan mendapat nilai langsung, tetapi menerapkan downgrade pada saat pembaruan untuk menghindari refund yang rumit.

Pilih kebijakan prorata yang bisa Anda jelaskan

Prorata bisa harian, per jam, atau tidak sama sekali. Semakin presisi, semakin banyak timestamp, aturan pembulatan, dan kasus tepi yang harus Anda simpan dan uji.

Kunci pilihan kebijakan lebih awal:

• Prorata upgrade segera, tunda downgrade hingga pembaruan
• Gunakan prorata harian (lebih sederhana daripada per jam, biasanya cukup adil)
• Definisikan aturan pembulatan (mis. dibulatkan ke atas ke sen terdekat)
• Putuskan bagaimana jeda bekerja (kredit waktu, atau perpanjang periode)
• Tetapkan kebijakan refund yang jelas untuk pembatalan (penuh, sebagian, atau tidak ada)

Modelkan prorata sebagai baris faktur

Hindari matematika tersembunyi. Representasikan prorata sebagai penyesuaian eksplisit pada faktur, seperti debit untuk waktu yang tersisa pada paket baru dan kredit untuk waktu yang tidak terpakai pada paket lama. Setiap baris harus merujuk event perubahan yang tepat yang menyebabkannya (change_id) dan menyertakan jendela prorata (start_at, end_at), kuantitas/basis waktu, dan kategori pajak.

Meter penggunaan menambahkan keputusan lagi: ketika paket berubah, apakah meter di-reset, tetap terakumulasi, atau dibagi menjadi segmen? Pendekatan sederhana dan dapat diaudit adalah membagi penggunaan berdasarkan versi paket. Contoh: pelanggan upgrade dari 10 seat ke 25 seat di tengah bulan. Anda menyimpan event penggunaan seperti adanya, tetapi rating mengelompokkannya berdasarkan periode entitlement yang aktif saat itu.

Putuskan apa yang reversibel. Berguna untuk memperlakukan event penggunaan sebagai final setelah diterima, sementara perubahan langganan mungkin hanya reversibel sampai faktur difinalkan. Simpan event perubahan dan penyesuaian faktur sehingga Anda bisa menghasilkan ulang faktur dengan rapi ketika aturan berkembang.

Data yang harus Anda simpan sejak hari pertama

Jika Anda menunggu mendesain data penagihan sampai setelah pelanggan mengeluh, Anda akan menebak. Baik Anda memilih langganan, penggunaan, atau model hybrid B2B SaaS, titik awal paling aman adalah sekumpulan catatan kecil yang selalu memungkinkan Anda diaudit nanti.

Mulailah dengan hierarki pelanggan yang jelas. Dalam B2B SaaS, pembayar biasanya akun perusahaan, tetapi penggunaan sering terjadi di dalam workspace atau proyek, dan aksi berasal dari pengguna individual. Simpan ketiga level itu (akun, workspace, pengguna) dan catat siapa melakukan apa. Sengketa penagihan sering berubah menjadi "tim mana yang melakukan ini?"

Desain basis data penagihan minimum yang mendukung faktur nyata dan investigasi bersih:

• Struktur akun dan organisasi: account, workspace (atau project), users, roles, kontak penagihan, dan kolom pajak jika diperlukan
• Subscriptions: paket, status, tanggal mulai/akhir, pengaturan perpanjangan, alasan pembatalan, dan versi harga yang diterapkan saat mulai
• Katalog harga: produk, komponen paket (biaya dasar, seat, meter), tier, mata uang, dan tanggal efektif
• Data metering penggunaan: log event append-only yang tak dapat diubah dengan timestamp, workspace, pengguna (jika tersedia), nama meter, kuantitas, dan kunci idempoten unik
• Artefak faktur: batas periode penagihan, baris faktur, total, penyesuaian pajak/diskon, dan snapshot input yang digunakan

Jangan hanya mengandalkan counter teragregasi. Simpan counter untuk kecepatan, tetapi anggap log event sebagai sumber kebenaran. Aturan sederhana membantu: event bersifat immutable, koreksi adalah event baru (mis. kuantitas negatif), dan setiap event terikat ke definisi meter spesifik.

Contoh: pelanggan berkata "API calls kami meningkat dua kali lipat bulan lalu." Jika Anda bisa menarik event mentah per workspace per hari, Anda bisa menunjukkan dari mana lonjakan itu berasal atau menemukan loop integrasi.

Langkah demi langkah: dari event penggunaan ke faktur

Bagian sulit bukanlah matematikanya. Bagian sulit adalah membuat hasilnya dapat dijelaskan beberapa bulan kemudian, bahkan setelah paket, harga, dan pelanggan berubah.

1) Mulai dengan katalog harga yang bisa melakukan time travel

Siapkan produk, paket, meter, dan harga dengan tanggal efektif. Jangan pernah menimpa harga lama. Jika seorang pelanggan ditagih pada Maret, Anda harus bisa menjalankan ulang Maret menggunakan katalog Maret.

Contoh: "API Calls" harganya $0.002 per panggilan mulai 1 April. Faktur bulan Maret harus tetap menggunakan tarif yang lebih lama.

2) Ambil snapshot apa yang pelanggan berhak dapatkan selama periode

Pada awal setiap periode penagihan (atau ketika perubahan terjadi), simpan snapshot entitlement: paket, unit yang termasuk, batas, aturan tier, diskon, dan pengaturan pajak. Anggap ini sebagai "apa yang kami janjikan" untuk periode itu.

3) Masukkan event penggunaan dan validasi sejak awal

Penggunaan harus datang sebagai event immutable: timestamp, pelanggan, meter, kuantitas, dan id unik untuk deduplikasi. Validasi dasar saat penerimaan (meter hilang, kuantitas negatif, timestamp mustahil) dan catat event mentah bahkan jika Anda juga menyimpan versi yang dibersihkan.

Lalu lakukan perhitungan dalam dua lintasan:

• Agregasikan event menjadi total per pelanggan, meter, dan periode penagihan (dan simpan versi agregasi)
• Nilai total tersebut menjadi biaya menggunakan katalog plus snapshot entitlement (unit yang termasuk, harga overage, tier)

Hasilkan baris faktur yang merujuk input tepat yang digunakan (versi katalog, id snapshot, id agregasi).

Akhirnya, kunci faktur. Simpan input dan hasil kalkulasi, tandai sebagai final, dan hentikan perubahan ketika event terlambat datang. Event terlambat harus masuk ke faktur berikutnya (atau penyesuaian terpisah) dengan catatan audit yang jelas.

Kebutuhan pelaporan pelanggan dan internal

Pelanggan tidak peduli apakah Anda memilih langganan atau penagihan berbasis penggunaan. Mereka peduli bahwa angka Anda cocok dengan milik mereka, dan bahwa mereka dapat memprediksi biaya berikutnya sebelum terjadi.

Pelaporan yang ditujukan ke pelanggan bekerja paling baik sebagai halaman penagihan sederhana yang menjawab beberapa pertanyaan tanpa membuka tiket dukungan:

• Paket apa yang saya miliki, dan apa yang termasuk?
• Berapa banyak yang telah saya gunakan periode ini, dan bagaimana penggunaan dihitung?
• Apa batas saya, dan apa yang terjadi jika saya melewatinya?
• Kapan periode penagihan berakhir, dan berapa estimasi tagihan saya berikutnya?
• Di mana saya bisa melihat faktur dan pembayaran sebelumnya?

Secara internal, dukungan dan keuangan perlu menjelaskan sebuah angka, bukan sekadar menampilkannya. Itu berarti mendeteksi lonjakan, melacak perubahan, dan memisahkan perhitungan pratinjau dari penagihan yang difinalkan.

Jaga pratinjau tagihan terpisah dari faktur. Pratinjau dapat dihitung ulang ketika penggunaan terlambat datang atau ketika Anda menyempurnakan definisi meter. Faktur tidak boleh.

Pelaporan internal Anda harus memudahkan untuk menandai anomali (lonjakan penggunaan mendadak, penggunaan negatif, event duplikat), mereproduksi baris faktur dari penggunaan mentah dan aturan, serta melihat perubahan paket dan aturan prorata untuk periode tersebut.

Jejak audit lebih penting daripada yang diperkirakan banyak tim. Jika seorang pelanggan mengatakan, "Kami upgrade pada tanggal 12," Anda butuh timestamp, pelaku (pengguna, admin, automasi), dan nilai before/after tepat untuk paket, seat, batas, dan tarif meter.

Untuk retensi, simpan event penggunaan mentah dan artefak faktur yang final untuk jangka panjang. Aturan praktis: jika itu bisa mengubah jumlah yang ditagihkan atau membantu mempertahankannya dalam sengketa, simpan secara immutable.

Perangkap umum yang menyebabkan sengketa penagihan

Sebagian besar sengketa penagihan bukan soal harga. Mereka terjadi ketika Anda tidak bisa menjelaskan angka di faktur, atau ketika input yang sama menghasilkan total yang berbeda nanti.

Kesalahan umum adalah hanya menyimpan total bulanan. Tanpa event mentah, Anda tidak bisa menjawab pertanyaan sederhana seperti "Hari mana yang membuat kami melewati batas?" Simpan event, lalu agregasikan.

Masalah lain adalah mengubah arti sebuah meter tanpa melacaknya. "Pengguna aktif" mungkin awalnya berarti "masuk setidaknya sekali" dan kemudian berubah menjadi "membuat record." Jika Anda tidak memversi definisi meter, pelanggan akan membandingkan faktur lama dengan yang baru dan Anda tidak bisa membuktikan aturan mana yang berlaku.

Sengketa sering datang dari pola yang sama:

• Entitlements hanya ditegakkan di UI (backend masih mengizinkan penggunaan ekstra atau memblokir penggunaan valid)
• Satu field timestamp digunakan untuk semua hal (waktu event, waktu ingest, waktu periode penagihan)
• Zona waktu diabaikan (penggunaan pada 00:30 waktu lokal masuk ke hari atau bulan yang salah)
• Anchor penagihan terlupakan (beberapa pelanggan menagih pada tanggal 1, yang lain pada tanggal signup)
• Tidak ada jejak audit perubahan paket, harga, dan batas

Contoh: pelanggan di Tokyo upgrade di tengah siklus pada tanggal 31 waktu lokal. Jika Anda hanya menyimpan timestamp UTC dan tidak menyimpan anchor penagihan, upgrade bisa tampak terjadi pada tanggal 30 di sistem Anda, memindahkan prorata dan penggunaan ke periode yang salah.

Cara tercepat kehilangan kepercayaan adalah tidak punya cara untuk mereproduksi kalkulasi faktur lama. Simpan input (event, versi, anchor, dan harga yang diterapkan) sehingga Anda bisa menjalankan ulang logika yang sama nanti dan mendapatkan hasil yang sama, bahkan setelah produk Anda berubah.

Pemeriksaan cepat sebelum meluncurkan penagihan

Sebelum Anda luncurkan, lakukan satu latihan: pilih pelanggan acak dan buat ulang faktur terakhir mereka hanya dengan data yang disimpan. Jika Anda membutuhkan "apa pun yang kode lakukan saat itu," berarti Anda tidak punya jejak audit.

Pastikan setiap meter tak ambigu. Sebuah meter butuh unit yang jelas (request, seat, GB, menit), sumber tepercaya (layanan mana yang mengeluarkannya), dan jendela waktu (per hari, per periode penagihan, per bulan kalender). Jika Anda tidak bisa menjelaskan meter dalam satu kalimat, pelanggan tidak akan mempercayainya.

Pemeriksaan cepat yang menangkap sebagian besar masalah penagihan:

• Anda dapat memutar ulang faktur dari input: versi paket, harga, total penggunaan, pajak, diskon, dan parameter prorata
• Event penggunaan bersifat append-only, immutable, dan dideduplikasi (kunci idempoten atau id event)
• Perubahan paket dan harga diberi versi dengan tanggal efektif (jangan menimpa harga lama)
• Aturan prorata tertulis dengan bahasa sederhana dan tercakup oleh tes
• Dukungan bisa menjawab "kenapa saya dikenai biaya" dengan cepat menggunakan fakta yang sama yang disimpan

Contoh: pelanggan upgrade dari 10 ke 25 seat pada tanggal 18 dan melewati threshold penggunaan pada tanggal 23. Sistem Anda harus menunjukkan (1) versi paket mana yang aktif pada setiap tanggal, (2) event perubahan seat dengan timestamp, (3) rumus prorata yang digunakan, dan (4) event penggunaan yang digabungkan menjadi total akhir.

Langkah selanjutnya: implementasi tanpa menjebak diri sendiri

Mulailah kecil, tapi jangan mulai secara samar. Jalur paling aman adalah model data terkecil yang masih memungkinkan Anda menjawab satu pertanyaan beberapa bulan kemudian: "Kenapa kami menagih jumlah ini?"

Prototipe skema penagihan dan layar admin lebih awal, sebelum perubahan harga pertama Anda. Jika Anda menunggu sampai tim sales meminta tier baru atau upgrade di tengah siklus, Anda akan menambal logika di banyak tempat.

Pembagian praktis: biarkan Stripe menangani charging, resi, dan percobaan pembayaran ulang, tetapi simpan rating (bagaimana penggunaan menjadi baris faktur) di sistem Anda sendiri. Itu berarti Anda menyimpan event penggunaan mentah, versi harga, dan hasil perhitungan yang Anda gunakan untuk menghasilkan pratinjau faktur.

Rencana peluncuran sederhana yang tetap fleksibel:

• Pilih 1-2 meter yang bisa Anda ukur dengan andal (mis. seat aktif per hari dan API calls)
• Versikan aturan harga sejak hari pertama agar faktur lama tetap cocok dengan aturan lama
• Bangun panel admin penagihan internal untuk melihat penggunaan, override, kredit, dan sengketa
• Tambahkan tampilan portal pelanggan dasar: paket saat ini, penggunaan periode saat ini, estimasi tagihan
• Perlakukan setiap faktur sebagai snapshot yang dapat diaudit, bukan tebakan yang dihitung ulang

Jika Anda ingin bergerak cepat tanpa menulis banyak kode back office kustom, Anda bisa memodelkan entitas ini di AppMaster dan membangun layar admin serta portal dengan alat visualnya, sambil menjadikan PostgreSQL sebagai sumber kebenaran untuk event dan faktur.

Contoh konkret: Anda meluncurkan dengan satu meter seat. Tiga bulan kemudian Anda menambahkan storage GB. Jika meter, entitlements, dan aturan harga diberi versi, Anda bisa memperkenalkan meter baru tanpa merusak faktur lama, dan dukungan dapat menjelaskan setiap baris faktur dalam hitungan menit.