Product Decisions This Supports
- Build vs. buy for the subscription core. This package covers plans, plan–feature entitlements, feature consumption/quotas, and renewal scheduling as Eloquent-native models. That lets us defer building (and maintaining) the subscription domain ourselves and redirect engineering toward differentiating product work.
- Pricing and packaging roadmap. Plan tiers and per-plan feature limits are first-class concepts, so we can ship tier changes, trials, and quota adjustments as configuration/data changes rather than schema migrations and new code paths.
- Feature gating and monetization experiments. Tying feature access to plan subscriptions supports gating premium capabilities, upsell prompts, and gated trials without a parallel entitlement system.
- Renewal and lifecycle behavior. Renewal handling is where churn, revenue recognition, and access revocation converge. Patch-level fixes here (like 4.3.2) directly affect whether customers keep or lose access at the right moment.
- Scope boundary with billing. This is subscription state and entitlements, not payment collection. It complements a payment provider (e.g., Cashier/Stripe Billing) rather than replacing invoicing, dunning, tax, or PCI-scoped flows.
Signal from 4.3.2: a hotfix correcting preset expiration being applied during renewals for plans with no periodicity (i.e., lifetime/non-expiring plans). Practically, that means non-recurring plans were at risk of being given an expiry they should never have had. If we sell any lifetime, one-off, or perpetual-license tier, this is a must-take patch and a prompt to audit our own plan configurations for the no-periodicity case.
When to Consider This Package
Adopt when:
- The product is Laravel/PHP and the team is already fluent in Eloquent; the package's value is largely in fitting existing model conventions.
- We need plans + feature entitlements + consumption tracking as a coherent unit, and the alternative is hand-rolling that domain.
- We want provider-agnostic subscription state — i.e., we may change or add payment providers, or handle invoicing outside the app.
- The team accepts a small, single-maintainer dependency for a revenue-adjacent concern, with the ability to fork or vendor if needed.
Look elsewhere when:
- Requirements include complex billing: proration, dunning, tax/VAT, invoicing, revenue recognition, multi-currency price books. Use the payment provider's billing engine (Stripe Billing / Laravel Cashier) and keep entitlement logic thin.
- We need enterprise entitlement semantics — seat-based licensing, contract terms, negotiated overrides, audit-grade history — where a dedicated entitlements/CPQ system is warranted.
- The stack is not Laravel, or the team would be fighting the package's conventions rather than benefiting from them.
- Maintenance risk is unacceptable. A hotfix in the renewal path is normal and healthy, but the bus factor of a single maintainer on revenue-critical logic should be an explicit, accepted trade-off — with a plan for pinning versions, regression tests around our plan matrix, and a fork path if upstream stalls.
How to Pitch It (Stakeholders)
To executives: We can avoid building a subscription and feature-entitlement engine in-house — a multi-week effort with ongoing maintenance cost — by adopting a focused Laravel package for plan state, feature access, and renewals. It handles subscription logic, not money movement; payments stay with our existing provider, so we are not adding financial or compliance risk. The project is actively maintained: 4.3.2 is a prompt hotfix in the renewal path, fixing an edge case where non-expiring plans could be incorrectly given an expiration date. We should take that patch, and confirm our lifetime/one-off plan behavior in QA.
To engineering: Eloquent-native plans, features, and consumable quotas with renewal scheduling built in — no custom schema or state machine to own. The 4.3.2 change is a narrow fix to renewal-time expiration presets for plans with no periodicity, so upgrade is low risk but should be paired with a regression test covering plans that must never expire. Expect a small dependency surface and a single primary maintainer, so pin the version, keep our plan-configuration tests around it, and treat any future fork as a known, low-cost contingency.