Laraplans Laravel Package

Product Decisions This Supports

• Tiered plan definition and packaging: Model Free/Basic/Pro plans as first-class records, with features attached as structured metadata. Useful for roadmap decisions about what each tier includes and when to re-cut the packaging as the product matures.
• Feature gating and entitlement checks: Drive paywall and upgrade-prompt decisions with a simple hasFeature()-style check rather than hard-coding plan logic across the app. This is the core PM-relevant capability: it lets you ship a premium feature once and decide later which tiers unlock it.
• Trial and conversion mechanics: Supports time-boxed subscriptions/trials with scheduled expiry, enabling experiments around trial length, renewal windows, and downgrade behavior without bespoke jobs.
• Build vs. buy for subscription plumbing: Replaces a sprint or two of custom plans/subscriptions/features schema and renewal logic with a small, MIT-licensed dependency. Frees engineering to focus on the product surface rather than the billing-adjacent bookkeeping.
• Internal/early-stage use cases: Good fit for MVPs, private betas, B2B seat-style tiers, or internal tools that need "which plan is this account on and what does it unlock" without a full billing stack.
• Downgrade/upgrade path design: Persisted subscription state lets you reason about grandfathering, proration-adjacent messaging, and feature sunset per tier — decisions that are painful once subscriptions are hard-coded.

When to Consider This Package

Adopt when:

• You need plan-to-feature mapping and simple recurring subscription records, not a payment processor.
• Your tiers are static enough that plan/feature changes are infrequent config edits.
• You already have (or will separately add) Stripe, Paddle, or similar for actual charging, invoicing, tax, and dunning.
• You want a lightweight, MIT-licensed dependency and are comfortable with a small community (sub-200 stars, modest ecosystem).
• Your team is Laravel-native and values convention over a heavier platform.

Look elsewhere when:

• You need metered/usage-based billing, seat proration, complex upgrade/downgrade money math, or revenue recognition.
• You require enterprise-grade invoicing, tax handling, or dunning — pair with Cashier or a billing platform, or choose Laravel Spark/Stripe Billing directly.
• You need a large ecosystem, long-term vendor support, or extensive community answers; a 179-star package carries key-person and maintenance risk despite a recent (2025-09-15) release.
• Your plan logic is highly dynamic (per-customer negotiated pricing, feature flags per account) — a dedicated feature-flag or entitlements service may fit better.

How to Pitch It (Stakeholders)

For executives: A small, open-source (MIT) Laravel package that gives us plan tiers, recurring subscription records, and feature gating out of the box. It removes roughly a sprint of custom subscription plumbing and lets us cut and re-cut pricing tiers as a config change rather than a code project — directly accelerating time-to-revenue for paid tiers. It is not a billing engine: we still need Stripe/Paddle for payments, tax, and invoicing, and we should treat it as internal plumbing rather than a customer-facing system.

For engineering: Low integration cost, idiomatic Laravel, maintained as of late 2025, but small community and limited long-term support signal. Recommend containing it behind our own entitlement interface so we can swap it for a billing platform or feature-flag service without touching product code. Pair it with Cashier (or equivalent) for money movement from day one rather than bolting billing on later.