Subscriptionify Laravel Package

Product Decisions This Supports

• Build vs. buy for entitlements. This package is an entitlement resolution layer (plans → features → quotas), not a billing system. It answers "what is this account allowed to do right now?" — deciding to adopt it means deciding not to hand-roll feature-flag-plus-quota logic in your own models, and instead owning only the mapping of your domain actions to slugs.
• Packaging and pricing tiers. The plan/feature/quota model maps directly to SKU design: which capabilities sit behind which tier, what the numeric limits are, and — per this release — how an additive grant on top of a plan differs from an override of unit price or reset cycle. That distinction is a pricing decision, not just a code decision; the release makes the semantics explicit enough to put in a pricing spec.
• Feature gating and upsell surfaces. featureInfo() returning correct data per slug means gating decisions can be made at the point of use ("can this workspace add a 5th seat?") rather than at page-render time. That supports progressive upsell UI, soft limits, and "you're 2 seats from your cap" prompts without bespoke query logic per surface.
• Entitlements inheritance across an account hierarchy. The newly documented "entitlements without a subscription" pattern — mirroring a parent's plan onto child records — enables org → team → project, or agency → client → sub-account structures, without provisioning a subscription per child. This is a roadmap-unlocking capability for multi-tenant and B2B2C products that were previously forced into fake subscriptions.
• Comp accounts, trials, beta access, and support overrides. grantFeature() resolving with no subscription present means growth/support can hand out capability without touching billing: design-partner access, service credits, migration grandfathering, VIP flags. Previously these had to be modeled as a degenerate plan; now they're a first-class, cheap operation.
• Data contract and API surface decisions. subscriptionInfo() is a serializable DTO and its features collection changed shape in this release. Any product surface that ships entitlements to a client (mobile app, SPA bootstrap payload, public API) inherits that contract — worth a deliberate decision on whether entitlement lists are client-visible, and on versioning them.
• Build sequencing. Because grants and plan entitlements now resolve through one path, a team can ship direct grants first (fast, no billing integration) and layer subscriptions later, or vice versa — the entitlement read path is stable across both.

When to Consider This Package

Consider adoption when:

• Your product already sells (or plans to sell) tiered plans where tiers differ by capability plus numeric limits — seats, API calls, projects, storage — rather than by a flat on/off flag.
• You need entitlements to be queryable server-side at the moment of action (policy checks, API middleware, queue workers), not merely decorative in the UI.
• You have — or anticipate — a parent/child account hierarchy where the child should inherit the parent's capabilities without its own billing relationship. The newly documented grant-only path is the specific thing to evaluate here.
• Non-billing exceptions are a real workflow: comped accounts, grandfathering, beta flags, support-issued overrides. If these currently live in spreadsheets or hardcoded email allowlists, this package replaces that.
• You want to avoid coupling entitlement logic to a specific payment provider. This is a Laravel-native model over your own tables; it does not require Stripe/Cashier-shaped data, which matters if you may change processors or sell through invoicing/resellers.
• Your team is Laravel-fluent and small. The integration cost is low relative to building and, more importantly, maintaining quota-overlap semantics correctly over time.

Look elsewhere when:

• You only need boolean feature flags. LaunchDarkly/Unleash/laravel-pennant cover toggles and percentage rollouts, which is a different problem; this package won't do gradual rollout or experimentation targeting.
• You need usage-based/metered billing as the core model. Metered aggregation, proration, invoices, dunning, tax — that's a billing platform's job. This resolves entitlements; it does not bill.
• You need real-time or high-frequency reads at very large scale. Entitlement checks derived from relational plan/grant data will need caching strategy work; if you're checking limits on every request across millions of users, validate the query and cache story before committing.
• You require a vendor SLA or commercial support contract. This is an early-version (1.0.x) open-source package with a single-maintainer release cadence visible in the changelog. That's fine for many products, but it's a procurement fact.
• Your entitlements are entirely defined by an external system of record (e.g. your ERP or the payment provider is authoritative and you only mirror it). Introducing a second authoritative model creates reconciliation work.
• You can't absorb a DTO contract change. The behavior change in 1.0.2 is a preview: consumers of subscriptionInfo() should expect the serialized shape to evolve. If downstream clients are third parties on a fixed contract, budget for a translation layer.

How to Pitch It (Stakeholders)

For executives — the short version. This is a small, focused library that lets us sell and enforce tiered plans without building a billing-adjacent subsystem ourselves. The 1.0.2 release broadens it from "subscription features" to a general entitlements engine: we can now grant capabilities to an account that has no subscription at all. That directly reduces time-to-market for enterprise/compoed deals, partner and beta access, and parent-child account structures that we'd otherwise have to improvise. It's an open-source dependency on a 1.0.x package — low cost to adopt, low cost to exit, but no vendor support, so treat it as a maintained-by-us dependency rather than a procured platform.

For engineering — why it's worth the dependency. We get a resolved answer to "what can this account do" from one API, with the semantics that are usually the source of bugs spelled out: overlapping plan and grant on the same slug deduplicates and adds the quota, while unit price and reset cycle are overridden, not summed. That's the rule we would have gotten wrong by hand. Grants resolve correctly with no subscription present, so comp accounts and inherited entitlements don't need fake subscriptions or a parallel code path — one read path covers both. The trade-off is a small public surface with one maintainer and a changelog that shows real behavior changes (1.0.2 alters what subscriptionInfo() serializes), so we should pin versions, keep entitlement reads behind our own thin service, and read the changelog on upgrade. Integration is a mapping exercise: our domain actions to feature slugs, our limits to quota values. That's a day or two, versus the weeks of incremental correctness work the overlap rules represent.