Databaseschema voor plannen en toegangsrechten dat upgrades, add-ons, proefperiodes en intrekkingen ondersteunt zonder hardcoded regels, met duidelijke tabellen en controles.
Op een prijspagina lijken plannen eenvoudig: Basic, Pro, Enterprise. De rommel begint zodra je die namen in echte toegangsregels binnen je app probeert om te zetten.
Hardcoded feature-checks (zoals if plan = Pro then allow X) werken voor de eerste versie. Daarna verandert de prijsstelling. Een functie verhuist van Pro naar Basic, er verschijnt een nieuwe add-on, of een sales-deal bevat een custom bundle. Plotseling staat diezelfde regel gekopieerd in API's, UI, mobiele apps en background jobs. Je verandert één plek en vergeet een andere. Gebruikers merken het.
Een tweede probleem is tijd. Abonnementen zijn geen statische label; ze veranderen midden in een periode. Iemand upgrade vandaag, downgrade volgende maand, pauzeert of annuleert terwijl er nog betaalde tijd over is. Als je database alleen de “huidige plan” opslaat, verlies je de tijdlijn en kun je later geen basisvragen meer beantwoorden: wat hadden ze afgelopen dinsdag? Waarom keurde support een terugbetaling goed?
Add-ons maken het erger omdat ze planafsnijdend zijn. Een add-on kan extra seats ontgrendelen, een limiet wegnemen of een specifieke functie inschakelen. Mensen kunnen het op elk plan kopen, later verwijderen of behouden na een downgrade. Als de regel in code zit, eindig je met een groeiende stapel speciale gevallen.
Dit zijn situaties die naïeve ontwerpen meestal breken:
Het doel is simpel: een flexibel toegangsmodel dat verandert met prijswijzigingen, zonder elke keer bedrijfslogica te herschrijven. Je wilt één plek om te vragen “mag dit?” en een databaan die het antwoord uitlegt.
Aan het einde van dit artikel heb je een schemapatroon dat je kunt kopiëren: plannen en add-ons worden inputs, en entitlements worden de enige bron van waarheid voor feature-toegang. Diezelfde aanpak past ook bij no-code builders zoals AppMaster, omdat je de regels in data kunt houden en consistent vanuit je backend, webapp en mobiele apps kunt opvragen.
Veel abonnementsproblemen beginnen als een vocabulaireprobleem. Als iedereen hetzelfde woord anders gebruikt, verandert je schema in speciale gevallen.
Houd deze termen gescheiden in een plans- en entitlements-databaseschema:
Feature flags zijn verwant maar anders. Een feature flag is typisch een product-schakelaar die je bestuurt (rollouts, experimenten, een feature uitzetten tijdens een incident). Een entitlement is klant-specifieke toegang op basis van wat ze betalen of wat je hebt toegekend. Gebruik flags wanneer je gedrag voor groepen wilt veranderen zonder met billing te rommelen. Gebruik entitlements wanneer toegang moet overeenkomen met een abonnement, factuur of contract.
Scope is een andere bron van verwarring. Houd deze ideeën duidelijk:
Tijd is belangrijk omdat toegang verandert. Modelleer het direct:
Voorbeeld: een bedrijf zit op Pro, voegt halverwege de maand “Advanced Reporting” toe en plant later een downgrade naar Basic. Het plan verandert later, de add-on start nu, en de entitlement-laag blijft de enige plek om te vragen: “Mag deze workspace vandaag advanced reports gebruiken?”
Een goed plans- en entitlements-databaseschema begint klein: scheid wat je verkoopt (plannen en add-ons) van wat mensen kunnen doen (features). Als je die twee ideeën helder houdt, worden upgrades en nieuwe add-ons datawijzigingen, geen herschrijvingen.
Hier is een praktische set tabellen die voor de meeste abonnementsproducten werkt:
products op en gebruiken een product_type-kolom.plan_features als je plannen scheidt): een join-tabel die zegt welke features bij welk product horen, meestal met een waarde.Die join-tabel is waar de meeste kracht zit. Features zijn zelden alleen aan of uit. Een plan kan max_projects = 10 bevatten, terwijl een add-on +5 toevoegt. Dus product_features moet ten minste ondersteunen:
feature_value (nummer, tekst, JSON, of aparte kolommen)value_type (boolean, integer, enum, json)grant_mode (replace vs add), zodat een add-on “5 seats toevoegen” kan doen in plaats van de basislimiet te overschrijvenModelleer add-ons ook als producten. Het enige verschil is hoe ze worden gekocht. Een basisplanproduct is “één tegelijk”, terwijl een add-onproduct mogelijk hoeveelheid toestaat. Maar beiden mappen op features op dezelfde manier. Dit voorkomt speciale gevallen zoals “als add-on X dan enable feature Y” verspreid door je code.
Features moeten data zijn, geen codeconstanten. Als je feature-checks hardcoded in meerdere services hebt, zal je uiteindelijk mismatches uitrollen (web zegt ja, mobiel zegt nee, backend is het oneens). Wanneer features in de database leven, kan de app één consistente vraag stellen en kun je wijzigingen doorvoeren door rijen te bewerken.
Naamgeving is belangrijker dan men verwacht. Gebruik stabiele identifiers die nooit veranderen, zelfs niet als de marketingnaam verandert:
feature_key zoals max_projects, sso, priority_supportproduct_code zoals plan_starter_monthly, addon_extra_seatsHoud displaylabels apart (feature_name, product_name). Als je AppMaster’s Data Designer met PostgreSQL gebruikt, betaalt het zich direct uit om deze keys uniek te hebben: je kunt veilig regenereren en integraties en rapportage blijven stabiel.
De meeste abonnementsystemen gaan mis wanneer “wat ze gekocht hebben” in één plek staat, maar “wat ze kunnen doen” in vijf verschillende codepaden wordt berekend. De oplossing is een entitlement-laag: een enkele tabel (of view) die effectieve toegang voor een subject op een tijdstip representeert.
Als je een plans- en entitlements-databaseschema wilt dat upgrades, downgrades, trials en eenmalige gunningen overleeft, is deze laag wat alles voorspelbaar maakt.
Zie elke rij als één claim: “dit subject heeft toegang tot deze feature met deze waarde, van deze tijd tot die tijd, vanuit deze bron.” Een gangbare vorm ziet er zo uit:
Je kunt value op een paar manieren implementeren: één tekst/JSON-kolom plus een value_type, of aparte kolommen zoals value_bool, value_int, value_text. Houd het saai en makkelijk te queryen.
Features zijn niet altijd aan/uit. Deze waardetypen dekken meestal echte billing- en toegangscontrolebehoeften:
Conflicten zijn normaal. Een gebruiker kan op een plan zitten dat 5 seats toestaat, een add-on kopen voor 10 extra en ook een handmatige toekenning van support krijgen.
Stel een duidelijke regel in en houd je er overal aan:
Een eenvoudige aanpak is alle kandidaat-rijen op te slaan (plan-afgeleide, add-on-afgeleide, direct) en een uiteindelijke “winnaar” per subject_id + feature_id te berekenen door te sorteren op source-precedentie en dan nieuwste starts_at.
Hier is een concreet scenario: een klant downgrades het plan vandaag, maar heeft al een add-on betaald die tot het eind van de maand loopt. Met starts_at/ends_at op entitlements gaat de downgrade direct in voor plan-gebaseerde features, terwijl de add-on feature actief blijft tot de ends_at. Je app kan met één query antwoorden op “mogen ze?” in plaats van speciale-case logica.
Je plancatalogus (plannen, add-ons, features) is het “wat.” Abonnementen zijn het “wie heeft wat, en wanneer.” Als je deze gescheiden houdt, worden upgrades en annuleringen minder eng.
Een praktisch patroon is: één subscription per account en meerdere subscription_items eronder (één voor het basisplan, plus nul of meer add-ons). In een plans- en entitlements-databaseschema geeft dit je een schone plek om veranderingen over tijd vast te leggen zonder toegangsregels te herschrijven.
Je kunt het simpel houden met twee tabellen die makkelijk te queryen zijn:
Een veelvoorkomend detail: sla elk item met zijn eigen datums op. Zo kun je een add-on slechts 30 dagen toekennen, of een plan laten doorlopen tot het einde van een betaalde periode zelfs als de klant de verlenging annuleert.
Proratie, facturen en betalingspogingen zijn billing-problemen. Feature-toegang is een entitlement-probleem. Probeer niet “toegang te berekenen” uit factuurregels.
Laat in plaats daarvan billing-events subscription-records bijwerken (bijv. extend current_period_end, create a new subscription_item row, of set ends_at). Je app beantwoordt toegangsvragen dan vanuit de subscription-tijdlijn (en later vanuit de entitlement-laag), niet vanuit billing-wiskunde.
Upgrades en downgrades treden vaak op een specifiek moment in:
Dit voorkomt hardcoded regels zoals “downgrades gebeuren aan het einde van de periode” in willekeurige delen van je code. Het schema is data.
Trials zijn gewoon tijdsgebonden toegang met een andere bron. Twee heldere opties:
Als je dit in AppMaster bouwt, mappen deze tabellen netjes naar de Data Designer in PostgreSQL, en maken de datums het eenvoudig om “wat is nu actief” te queryen zonder speciale gevallen.
Een goed plans- en entitlements-databaseschema begint met één belofte: featurelogica leeft in data, niet verspreid door codepaden. Je app moet één vraag stellen - “wat zijn de effectieve entitlements nu?” - en een helder antwoord krijgen.
Maak een feature-tabel met een stabiele, menselijk-leesbare sleutel die je nooit hernoemt (zelfs niet als het UI-label verandert). Goede keys zijn export_csv, api_calls_per_month of seats.
Voeg een type toe zodat het systeem weet hoe de waarde behandeld moet worden: boolean (aan/uit) vs numeriek (limieten/quotas). Houd het saai en consistent.
Nu heb je twee bronnen van waarheid nodig: wat een plan bevat, en wat elke add-on toekent.
Een eenvoudige, praktische volgorde is:
feature-tabel met stabiele keys en een value type.plan en plan_entitlement waar elke rij een featurewaarde toekent (bijvoorbeeld seats = 5, export_csv = true).addon en addon_entitlement die extra waarden toekennen (bijvoorbeeld seats + 10, api_calls_per_month + 50000, of priority_support = true).Als je dit in AppMaster bouwt, kun je deze tabellen modelleren in de Data Designer (PostgreSQL) en de combinatieregels als een kleine “policy”-tabel of enum opnemen die door je Business Process-logica wordt gebruikt.
Je hebt twee opties: bereken on read (query en merge elke keer) of genereer een gecachte snapshot wanneer er iets verandert (planwijziging, add-on aankoop, verlenging, annulering). Voor de meeste apps zijn snapshots makkelijker te begrijpen en sneller onder load.
Een veelgebruikte aanpak is een account_entitlement-tabel die het uiteindelijke resultaat per feature opslaat, plus valid_from en valid_to.
Verspreid regels niet over schermen, endpoints en background jobs. Zet één functie in de appcode die effectieve entitlements leest en beslist.
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
Zodra alles can(...) aanroept, worden upgrades en add-ons data-updates, geen herschrijvingen.
Een supportteam van 6 personen zit op het Starter-plan. Starter bevat 3 agent-seats en 1.000 SMS-berichten per maand. Halverwege de maand groeien ze naar 6 agents en willen een extra SMS-pack van 5.000. Je wilt dat dit werkt zonder speciale code zoals “als plan = Pro dan…”.
Je maakt een subscription voor het account met een betaalperiode (bijvoorbeeld 1 jan tot 31 jan). Dan voeg je één subscription_item voor het plan toe.
Bij checkout (of via een nightly job) schrijf je entitlement-gunningen voor die periode:
entitlement_grant: agent_seats, waarde 3, start 1 jan, eind 31 janentitlement_grant: sms_messages, waarde 1000, start 1 jan, eind 31 janJe app vraagt nooit “op welk plan zitten ze?” maar “wat is hun effectieve entitlement nu?” en krijgt seats = 3, SMS = 1000.
Op 15 jan upgraden ze naar Pro (bevat 10 agent-seats en 2.000 SMS). Je bewerkt geen oude gunningen. Je voegt nieuwe records toe:
subscription_item (Starter) end op 15 jansubscription_item (Pro) start 15 jan, end 31 jansubscription_item (SMS Pack 5000) start 15 jan, end 31 janDan worden gunningen voor dezelfde periode toegevoegd:
entitlement_grant: agent_seats, waarde 10, start 15 jan, eind 31 janentitlement_grant: sms_messages, waarde 2000, start 15 jan, eind 31 janentitlement_grant: sms_messages, waarde 5000, start 15 jan, eind 31 janWat gebeurt er direct op 15 jan?
Bestaand gebruik hoeft niet verplaatst te worden. Je gebruikstabel blijft berichten tellen; de entitlement-check vergelijkt gebruik deze periode gewoon met de huidige effectieve limiet.
Op 25 jan plannen ze een downgrade terug naar Starter vanaf 1 feb. Je raakt de gunningen van januari niet aan. Je maakt toekomstige items (of toekomstige gunningen) voor de volgende periode:
subscription_item (Starter) start 1 feb, end 28 feb1 febResultaat: ze behouden Pro-seats en het SMS-pack tot 31 jan. Op 1 feb daalt hun effectieve seats naar 3 en reset SMS naar Starter-limieten voor de nieuwe periode. Dit is makkelijk redeneerbaar en past netjes in een no-code workflow in AppMaster: datums veranderen creëert nieuwe rijen en de entitlement-query blijft hetzelfde.
De meeste abonnementsbugs zijn geen billing-bugs. Het zijn toegangsbugs veroorzaakt door verspreide logica door het product. De snelste manier om een plans- en entitlements-databaseschema te breken is “mogen ze?” in vijf verschillende plekken te beantwoorden.
Een klassiek falen is hardcoded regels in UI, API en background jobs apart. De UI verbergt een knop, de API vergeet het endpoint te blokkeren, en een nightly job draait nog steeds omdat die iets anders checkt. Je eindigt met verwarrende “het werkt soms”-meldingen die moeilijk te reproduceren zijn.
Een andere val is checks op plan_id in plaats van featurechecks. Het lijkt eenvoudig (Plan A kan exporteren, Plan B niet), maar het valt uit elkaar zodra je een add-on, een grandfathered klant, een gratis proef of een enterprise-exceptie toevoegt. Als je ooit zegt “if plan is Pro then allow…”, bouw je een doolhof dat je voor altijd moet onderhouden.
Toegang blijft ook “plakken” als je alleen een boolean zoals has_export = true opslaat en nooit datums toevoegt. Annuleringen, refunds, chargebacks en mid-cycle downgrades hebben allemaal tijdsgrenzen nodig. Zonder starts_at en ends_at geef je per ongeluk permanente toegang, of neem je toegang te vroeg weg.
Een eenvoudige check om dit te vermijden:
Teams krijgen ook problemen door billingrecords en toegangsregels in dezelfde tabel te mengen. Billing heeft facturen, belastingen, proratie, provider-IDs en retry-states nodig. Toegang heeft duidelijke feature-keys en tijdvensters nodig. Wanneer ze verstrengeld raken, wordt een billing-migratie een productstoring.
Tot slot slaan veel systemen geen audittrail op. Als een gebruiker vraagt “waarom kan ik exporteren?”, heb je een antwoord nodig zoals: “Ingeschakeld door Add-on X van 2026-01-01 tot 2026-02-01” of “Handmatig toegekend door support, ticket 1842.” Zonder dat raden support en engineering.
Als je dit in AppMaster bouwt, houd auditvelden in je Data Designer-model en maak de “mogen ze?”-check een enkele Business Process die web, mobiel en geplande flows gebruiken.
Voordat je je plans- en entitlements-databaseschema uitrolt, doe je één laatste ronde met echte vragen, niet theorie. Het doel is dat toegang verklaarbaar, testbaar en wijzigbaar is.
Kies één gebruiker en één feature, en probeer het resultaat uit te leggen zoals je dat aan support of finance zou doen. Als je alleen kunt antwoorden “ze zitten op Pro” (of erger, “de code zegt het”), krijg je pijn zodra iemand midden in de periode upgrade of een eenmalige deal krijgt.
Gebruik deze checklist:
feature.export_csv) in plaats van plan-namen (zoals “Starter” of “Business”)? Plannaam verandert; feature-key niet.Een praktische test: maak drie gebruikers (nieuw, mid-month geüpgraded, geannuleerd) en één add-on (bijvoorbeeld “extra seats” of “advanced reports”). Draai je toegangquery voor elk. Als de resultaten duidelijk en verklaarbaar zijn, ben je klaar.
Als je met een tool als AppMaster werkt, houd één regel: laat één plek (één query of één Business Process) verantwoordelijk zijn voor “mogen ze?”, zodat elk web- en mobiel scherm hetzelfde antwoord gebruikt.
De beste manier om upgrades beheersbaar te houden is kleiner beginnen dan je denkt. Kies een handvol features die echt waarde hebben (5–10 is genoeg) en bouw één entitlement-query of functie die één vraag beantwoordt: “Mag dit account X nu doen?” Als je dat niet in één plek kunt beantwoorden, blijven upgrades risicovol.
Als die ene check werkt, behandel upgradepaden als productgedrag, niet alleen als billinggedrag. De snelste manier om rare randgevallen te vangen is een klein setje access-tests te schrijven gebaseerd op echte klantbewegingen.
Praktische volgende stappen die vaak snel renderen:
Als je een no-code backend gebruikt, kun je dit patroon nog steeds duidelijk modelleren. In AppMaster is de Data Designer geschikt om de kerntabellen te maken (plannen, features, subscriptions, subscription items, entitlements). De Business Process Editor kan dan de toegangsgedachte vasthouden (laad actieve entitlements, pas tijdvensters toe, retourneer allow/deny) zodat je niet verspreid checks in endpoints handmatig codeert.
De winst zie je bij de volgende prijswijziging. In plaats van regels te herschrijven, bewerk je data: een feature verhuist van “Pro” naar een add-on, een entitlement-duur verandert, of een legacy-plan behoudt oude gunningen. Je toegangslogica blijft stabiel en upgrades worden een gecontroleerde update, geen code-sprint.
Als je je schema snel wilt valideren, probeer dan één upgrade plus één add-on end-to-end te modelleren en voer die access-tests uit voordat je iets anders toevoegt.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
