Laravel Subscriptions Laravel Package

Product Decisions This Supports

• Monetization v1: shipping paid plans without building billing primitives. Gives the team plans, features, subscriptions, and plan-feature relationships as first-class Eloquent models, so the roadmap item "introduce paid tiers" moves from a multi-sprint schema-and-state-machine project to an integration task. The PM decision it unblocks is when we can charge, not whether we can model charging.
• Build vs. buy for the subscription data model. The buy case is strongest here: subscription state (active, trialing, canceled, grace period, plan changes) is deceptively fiddly and rarely a differentiator. Using a package lets the team spend its differentiation budget on entitlement logic, onboarding, and pricing UX instead of subscription bookkeeping.
• Feature gating and packaging experiments. Because plans map to features, the PM can drive pricing/packaging changes (move feature X from Pro to Team, add a trial to the top tier) as configuration and data changes rather than engineering projects. This is the package's highest-leverage contribution to roadmap velocity: packaging becomes a product decision, not a migration.
• Upgrade/downgrade and trial flows. Supports the self-serve motions that drive expansion revenue — in-app upgrades, trial-to-paid conversion, cancellation with grace period — which is usually the difference between a pricing page and a revenue engine.
• Scope clarity for the billing roadmap. It is explicitly not a payment processor, invoicing system, tax engine, or dunning system. This forces a useful product decision early: the package owns what a customer is entitled to; a provider (Stripe/Paddle, typically via Laravel Cashier) owns money movement. Sequencing those two workstreams is a roadmap call this package makes explicit.
• De-risking the "do we need a billing vendor?" question. For an early SaaS, this plus Cashier is often enough to launch and learn. The PM decision it defers — migrating to a full billing platform — is cheaper to make later than to make prematurely.

When to Consider This Package

Adopt it when:

• You are building a Laravel SaaS on Laravel 10.x/11.x and need tiered plans, feature entitlements, trials, and plan switching as a data model, not as a payment integration.
• You are pre-product-market-fit or early revenue: the cost of being wrong about your subscription schema is low, and speed to a working pricing page matters more than billing edge-case completeness.
• Your team is comfortable with Eloquent and Laravel conventions and would rather own migrations and models than a black-box billing platform.
• You need custom entitlement semantics (seat counts, quota buckets, per-plan feature matrices) that a hosted billing product would force into its own vocabulary.
• MIT licensing and schema ownership matter to you — you can fork, extend, and keep the data in your own database.

Look elsewhere when:

• You need usage-based/metered billing, complex proration, multi-currency tax, invoicing, or dunning. Those are provider problems; use Stripe Billing or Paddle directly rather than bolting them onto a plans package.
• You are already committed to Stripe/Paddle as the source of truth — doubling up on subscription state creates reconciliation work with no upside. Use Cashier alone.
• You require vendor SLAs, security review, or enterprise support. This is a community package (Laravel Cameroon org), not a commercial product.
• Bus factor is a blocker. 244 stars and 0 dependents on Packagist is a thin adoption signal; assume you may be the maintainer of your fork. Verify tests, changelog cadence, Laravel-version support (the badge says 10.x), and issue responsiveness before committing.
• You need feature-flag maturity (targeting, gradual rollout, experimentation). Pair with a dedicated flag tool; don't stretch plan-feature rows into an experimentation platform.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is an MIT-licensed Laravel package that supplies the subscription and plan data model — plans, features, subscriptions, trials, plan changes — so we can launch paid tiers without building billing bookkeeping from scratch. It compresses a multi-sprint schema and state-machine effort into an integration task, and it makes future pricing/packaging changes configuration rather than engineering work. Critically, it does not move money: payments, invoices, tax, and dunning remain with a provider like Stripe. The trade-off is maintenance risk — small community project, modest adoption — which we mitigate by owning our fork and keeping the abstraction thin.

For engineering — the summary:

• What you get: Eloquent models and migrations for plans, features, plan-feature pivots, and subscriptions with lifecycle states; Laravel-native conventions, testable, no external service dependency, data stays in our DB.
• What you don't get: payment processing, proration math, invoicing, tax, dunning, refunds, or a webhook pipeline. Pair with Cashier/Stripe for money movement and keep the boundary explicit: this package answers "what is the customer entitled to?"; the provider answers "did they pay?"
• Integration work to scope: verify Laravel version support (README badge reads 10.x), map provider events onto package subscription states, define entitlement-check helpers for authorization/policy layers, and decide where plan changes are audited.
• Due diligence before adoption: test suite coverage, changelog/release cadence, open-issue responsiveness, and whether we're willing to fork. With 244 stars and no dependent packages, plan on a thin wrapper of our own so a swap is a contained change, not a rewrite.
• Recommendation: adopt behind an internal interface for the MVP; revisit if metered billing, tax, or enterprise invoicing enters the roadmap.