Skip to main content
SynaptaGrid Platform
← All capabilities
Available now

Platform capability · Plans, Features & Quotas

Sell plans with different limits, and let the platform enforce them

Define each plan limit once. The platform enforces it in your app

Feature access and numeric limits are handled by one system, separate from the payment provider. You define a feature or a limit together with the app that owns it. The platform then supplies the plan editor, overrides for single organizations, usage tracking, the check on each request and the values shown on the pricing page. Your product code calls the same feature and limit checks through the SDK.

Built in

What you get

  • On/off features and numeric limits in one model
  • A limit is set for the app, then for the plan, then for the organization. The most specific value applies
  • Overrides for one organization, for deals that do not fit the price list
  • Dedicated database and compute add-ons: customers pick a size in the portal, see its vCPU, memory, storage, backups and full price, and the plan changes with it
  • Usage counted as a running total, per day or per request
  • A limit is enforced when the request is made, so overuse does not first appear on the invoice
  • The plan comparison text comes from the same definition, so the pricing page matches what the product enforces
  • Add a new limit without writing enforcement code
  • Works the same with Stripe, Paddle or billing run in-house
  • One question from your product code: is this allowed, and how much is left
Under the hood

How it works

Feature and limit checks belong in the platform

A payment provider can tell you whether a customer has paid for a feature, and that part works well. It does not hold the number: 25 seats, 100,000 records, 10,000 runs a month. It does not know which of the customer’s environments a request belongs to, and it does not stop the request that goes over the limit. That check runs on every request, so it belongs next to the customer data and not in a billing account. Teams that find this out late end up building a second service in front of their payment provider, with a cache, a webhook listener and rules for out-of-date data to maintain.

One definition for plans, usage and request checks

A limit is declared together with the app that owns it: its name, its unit, its default and how usage is counted. Publishing the app adds the limit to the plan editor, makes it available for overrides, starts usage tracking and supplies the label and description your pricing page shows. These are normally five separate places: a database change, an admin screen, a lookup function, an enforcement call and a line of text on the marketing site. Over time some of them stop matching. Here there is one definition.

Plans and overrides for a single organization

Enterprise deals rarely match a published plan. You can raise one limit for one organization, give it a feature outside its plan, or build a custom plan for one customer. You do not copy your catalog or add special cases to product code. The override is read through the same chain of values, so your application gets a consistent answer.

Pairs well with

Related capabilities

Billing & Subscriptions

Plans, prices, invoices and metered usage

Organizations, Plans & Settings

One record of every customer, app, plan and setting, with overrides for each customer

App SDK

Register features, events, permissions, AI tools and infrastructure needs in one app declaration

Want a deeper walkthrough of Plans, Features & Quotas?

A solution architect will demo the live service against your domain model.

Get a deployment assessment