Plans and Entitlements

The problem

Packaging is where software companies quietly lie to their customers. A feature appears on the pricing page but the code never checks the flag, so it ships to everyone and the tier above it has nothing left to sell. Or the reverse: the gate is real but the plan data never grants it, and a customer who paid for Enterprise finds the button greyed out and opens a support ticket you cannot close without a deploy.

The failure is structural, not careless. The pricing page is a design file, the plan record is a database row, and the gate is an if statement in a service somebody else owns. Nothing makes the three agree, and nothing tells you when they stop.

What Solidlio does about it

One catalogue row per plan carries its prices, its seat rules, its feature flags and its numeric caps. Every gate in every service that has one — ten of them, from ticketing to AI — reads that row through the same shared helpers: no service keeps its own copy of what a plan includes, and no service writes its own comparison. Platform administrators edit the catalogue in the product, and the change applies to running tenants immediately, including to the upgrade offers customers are shown. A published matrix is generated from the same data, with a per-key enforcement badge, so “advertised but not enforced” is a visible state rather than a discovery.

And when a plan does block someone, it does not just refuse. The response carries the name of the cheapest plan that lifts the block, its price in the customer’s currency, and whether that particular user is allowed to buy it — so the interface can offer the upgrade in place instead of showing a red error.

Capabilities

Built for MSPs and their clients

Two tenants, two plans, one relationship. The MSP’s plan governs its own practice; each client’s plan governs that client. A managed client that has not bought a plan of its own inherits its MSP’s entitlements, so an MSP can bring a client onto the platform before any money changes hands.

How it works

1. Choose a plan. After signup the plan picker shows the ladder for your business type, priced in your account’s currency, with a seat selector that updates the estimate as you move it.
2. Start. Paid plans below Enterprise carry a 14-day trial; the rest invoice immediately. Enterprise is quoted.
3. Work. Feature gates and caps apply from that moment. Nothing is checked twice and nothing is cached stale — every gate reads the live plan.
4. Hit a wall. Creating a fifty-first asset on a fifty-asset plan returns the cap, the plan that raises it, its monthly price, and whether you personally can buy it. The interface shows an upgrade button or “ask your administrator”, never a stack trace.
5. Upgrade. Pay the prorated difference for the rest of the period. The new caps are written in the same transaction, so the action you were blocked on works on the next click.
6. Change your mind. Downgrades apply at renewal, through support, so you keep what you have paid for. Nothing is deleted when a plan shrinks — you simply stop being able to add more.

Compliance and audit

Every change to the plan catalogue writes a PlatformAuditLog entry with the acting administrator’s identity and email, the action, the tier, and the complete before and after state of the row. Tier creation and its audit entry are written in one transaction, so a plan cannot exist without a record of who created it. The same applies to per-currency price changes and deletions.

Plan changes on an account are recorded as platform orders and subscription events, so the sequence from trial to paid to upgrade to cancellation can be reconstructed, along with what was charged for each step.

A tier that any account or subscription is using cannot be deleted.

Editions

MSP / IT partner plans:

End-customer plans:

Every cell above is generated from the plan catalogue and cross-checked against the code that enforces it.

Priority support tiers (email, chat, phone) are a service commitment, not a software gate, and are excluded from these tables deliberately.

“API access” gates whether a plan may issue an API key. The Read/Full distinction sets the key’s recorded scope; it is not yet enforced per request.