Laravel Quotas Laravel Package

Product Decisions This Supports

• Plan and packaging design. The core value is separating what an account is entitled to from what it pays. That lets product define tiers (feature included/not included, seat counts, monthly allowances) as configuration rather than hardcoded conditionals, so pricing experiments and repackaging don't require engineering releases.
• Build vs. buy for the entitlement layer. This is the classic "small but pervasive" component: every gated feature, every counter, every upgrade prompt touches it. Buying a small MIT-licensed implementation defers 2–6 weeks of internal design work (schema for plans/entitlements/usage, atomic counter increments, limit-check API, edge cases around resets and timezones).
• Decoupling entitlements from billing. Keeping Cashier as the system of record for money, and this package as the system of record for permission-to-use, is the architecturally correct split. It means you can support manual contracts, invoiced enterprise deals, internal/test accounts, and grace periods without inventing fake subscriptions in Stripe.
• Metering and overage policy. Enables an explicit decision per feature: hard limit (block at ceiling), soft limit (warn then allow), or overage (allow and bill later). Making that a per-entitlement configuration rather than a code path is a roadmap unlock — you can ship "soft limits + upgrade nudge" before you ship real metered billing.
• Trial and onboarding design. Time-boxed or usage-boxed trial allowances become data, so growth/product can tune trial generosity without a deploy — a common growth lever that's painful when limits are hardcoded.
• Roadmap sequencing. Lets you ship paid tiers before sophisticated billing: gate features, count usage, invoice manually or via simple subscriptions, then invest in metered billing or a billing vendor only once volume justifies it.
• Pricing-change operations. Grandfathering, plan migrations, and per-account overrides are the operational reality of any SaaS pricing change. A dedicated entitlement layer with per-account override capability makes these one-off ops tasks instead of data migrations.

When to Consider This Package

Consider it when all of the following hold:

• You're a Laravel SaaS already using (or committed to) Cashier for billing, so the "billing stays with Cashier" boundary matches your stack.
• Your gating needs are moderate: feature flags per plan, seat caps, monthly API/usage counters, trial allowances. Not per-event, high-cardinality metering.
• You're pre-scale on billing complexity — you want entitlements now and can defer overage invoicing.
• Your team is small enough that a small, readable dependency you can fork is cheaper than designing the schema and limit semantics in-house.
• You accept owning the code: with 1 star, 0 dependents, and a single publisher, treat this as vendored source, not a vendor relationship. MIT makes that legitimate.

Look elsewhere (or build) when:

• Reliability and support are contractual requirements. Zero dependents means no field-tested edge cases and no community answer when something breaks. No security-review track record either — plan for an internal read-through of the source before it touches production.
• You need real metering at volume. Per-request counters in your app DB will not survive high event throughput; that's a job for Stripe metered billing, Orb, Metronome, or an event pipeline.
• You need authorization, not entitlement. Role/permission checks are Spatie's laravel-permission; experiment/rollout targeting is Pennant or a feature-flag service. Don't stretch this package into those roles.
• You need enterprise-grade audit, SSO-driven entitlements, or contract-based custom packaging across multiple products — you'll want a commercial entitlement/CPQ layer.
• You're not on Laravel/Cashier, or you're on a Laravel version outside whatever the package pins. Verify compatibility explicitly; a low-adoption package won't have broad matrix coverage.

Before committing, a PM should ask engineering to answer: Is the maintenance model credible (recent release + a plan for the "what if the maintainer stops" case)? Does the limit-check API cover atomic/race-safe increments for our concurrency? Can we express soft limits, overrides, and grace periods? Is there a migration path off it if needed?

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Laravel component that lets us sell tiered plans without hardcoding "if customer is on Pro" throughout the product. It separates what a customer is allowed to do from how they pay us — which means we can ship pricing changes, trials, and enterprise custom deals without engineering work each time, and without re-plumbing Stripe. It's cheap to adopt and cheap to abandon: MIT means if the maintainer disappears, we keep the code. Recommended position: adopt as a small, owned component behind our own thin interface — not as a strategic vendor.

To engineering: It gives you a plans/entitlements/usage model with a limit-check API, and it deliberately leaves billing to Cashier, which is the boundary you'd draw anyway. Caveats to own consciously: it's early-stage (single publisher, no downstream dependents), so we read the source before shipping, wrap it in our own Entitlements facade so we're not coupled to its API, and avoid it for high-throughput metering. Budget roughly a day of review plus a thin adapter — against several weeks to design and harden usage-counter semantics ourselves.

Key risks to state plainly: adoption risk (near-zero community), maintainer concentration, unproven edge-case behavior around concurrency, resets, and timezones, and no security track record. Mitigations: vendor/fork the source, wrap it behind an internal interface, add tests around the limits semantics we depend on, and cap scope to plan gating plus monthly counters.