Product Decisions This Supports
- Pricing & packaging changes without engineering cycles. Plans, features, currency prices, and featured-plan flags are editable in a Filament admin panel, so a PM can ship a new tier, reprice a market, or promote a "most popular" plan as a config change rather than a sprint. That directly shortens the loop between pricing hypothesis and live test.
- Monetization experiments. Discounts and promo codes (percentage/fixed, date-windowed, usage-capped, plan- or feature-targeted) give growth and marketing a self-serve lever for launch offers, win-back campaigns, and partner deals — with
markUsed() and validity checks providing the guardrails a PM needs to avoid margin leakage.
- Geographic and localized go-to-market. Multi-currency pricing plus translatable plan/feature content answers the "can we launch in IDR/EUR without a fork?" question, and locale→currency mapping means one pricing table serves all storefronts.
- Build vs. buy on the admin surface. Subbase is effectively "buy the back office": plan CRUD, subscription lifecycle states (trial/active/canceled/expired), feature-usage tracking, and a promotional pricing component. The buy case is strongest when the team's differentiation is not in subscription CRUD.
- Roadmap sequencing input. Because it sits on
laravelcm/laravel-subscriptions, it cleanly separates subscription state management (covered) from billing execution — payment capture, proration, dunning, tax/VAT, invoicing, revenue recognition (not covered). That boundary is a useful artifact for scoping "what we still own" on the billing roadmap.
- Prioritizing which subscription features are table stakes. Trials, plan swapping, feature gating, and usage limits arriving pre-built is evidence they're commodity; a PM can argue to reallocate the team's roadmaps toward metered/usage-based billing, entitlements enforcement, and billing ops — the areas this package does not solve.
When to Consider This Package
Adopt when:
- The product is a Laravel + Filament app already, and you want a subscription admin UI this quarter rather than next.
- Your model is flat-rate, tiered, or feature-gated plans with monthly/annual intervals — the shape this package models well.
- You need multi-currency display or localized plan content and don't want to build translation and currency tables from scratch.
- The team is small, the admin surface is internal (ops/support users), and a published Blade pricing component is acceptable as a starting point for the storefront.
- You're comfortable extending base models via config (
models bindings) and owning the payments layer yourself.
Look elsewhere when:
- You need a billing engine, not a subscription catalog: Stripe/Paddle/Chargebee webhooks, proration on upgrade/downgrade, retries and dunning, tax determination, invoice PDFs, revenue recognition. Subbase stops at state.
- Maturity and support risk are unacceptable. Signals here are thin: single maintainer, ~6 stars, zero dependents, empty release notes, and no external adoption to lean on. A one-person package in the revenue path is a bus-factor decision, not just a technical one — budget for the option of forking or replacing.
- Version compatibility is unproven on your stack. Requirements are PHP 8.2+, Laravel 13.7+, Filament 5.0+ — a forward-leaning, narrow window. Verify against your pinned versions before it enters a roadmap commitment.
- You need metered/usage-based billing, seat-based proration, or complex entitlements — the feature model here is assignment and usage counting, not a rating engine.
- Your admin isn't Filament, or you need audited, compliance-grade financial admin flows (SOC 2 style change history, approval workflows).
- You need multi-tenant, per-customer negotiated pricing or enterprise contract management; this is a catalog, not a CPQ tool.
How to Pitch It (Stakeholders)
Executive summary. Subbase is a free (MIT) Laravel package that supplies the back office of a subscription business — plan catalog, multi-currency pricing, trials and lifecycle states, feature entitlements, and a promo-code engine — behind a polished Filament admin panel, plus a usable pricing-table frontend component. It buys us weeks of internal-tooling work at zero license cost and lets marketing and ops change pricing and run promotions without engineering. It is not a billing system: payment processing, dunning, tax, invoicing, and revenue reporting remain ours. The real decision is not "should we build subscription CRUD" but "do we accept a young, single-maintainer dependency in a revenue-adjacent path?"
For engineering. Built on laravelcm/laravel-subscriptions, so core subscribe/cancel/swap/check-feature logic is delegated to a known base rather than reinvented; Subbase adds multi-currency price accessors (getPriceForCurrency, getPriceForLocale), translatable content via Spatie Translatable, discounts with plan/feature targeting and PlanPriceHelper::resolveWithDiscounts, customizable models through config, optional spatie/laravel-permission gating that degrades gracefully if absent, and publishable views/config/translations for override. Install path is subbase:install, migrate, a trait on User, and a plugin registration in the panel provider. Risks to size explicitly: narrow version constraints (Laravel 13.7+/Filament 5+), minimal release documentation, and no downstream usage to validate upgrade paths — so pin the version, publish and own the views and config, and treat any fork as a maintained internal asset.
Recommendation. Time-boxed evaluation, not a permanent commitment: pilot it behind one pricing page and the internal admin, with the payments layer untouched, and a stated exit criterion — if the maintainer goes quiet or a Filament/Laravel upgrade breaks it, we fork the config and models we've already published. Approve only if the pilot ships inside a sprint or two; otherwise the cost of adopting a low-traction dependency exceeds the build it replaces.