Subkit Laravel Package

Product Decisions This Supports

• MVP acceleration / build-vs-buy on billing: This is a credible “buy the boilerplate” option for the subscription CRUD layer — plans, subscriptions, and lifecycle state — so the team can spend its first sprint on differentiated product work instead of reinventing a billing schema and admin screens.
• Self-serve monetization roadmap: If the roadmap calls for tiered plans, trials, upgrades/downgrades, and a customer-facing or admin-facing subscription view, this package short-circuits weeks of scaffolding. It is a delivery accelerant for a pricing-page-to-checkout flow, not a pricing strategy in itself.
• Support & operations tooling: The Filament UI matters more than it first appears — it gives support and finance-adjacent roles a place to inspect and adjust subscriptions without engineering tickets. That is a real operational cost reduction and a reason to choose it over raw Cashier.
• Scope triage for the platform team: Adopting it is effectively a decision to not build a billing domain team yet. That is the right call pre-product-market-fit and the wrong call once billing becomes a competitive surface (usage-based metering, multi-currency, dunning logic, revenue recognition).
• Stack-fit as a forcing function: Because it assumes Laravel + Filament + Stripe, it is a useful lens for a “standardize the admin stack” decision — if you adopt it, you are also implicitly endorsing Filament as the internal-tools layer.

When to Consider This Package

Consider it when all of the following hold:

• The product is a Laravel application and the team is already comfortable with Cashier; you want the missing admin/UI layer, not a new billing engine.
• Stripe is the only payment processor you need for the next 12–18 months — no multi-PSP, no regional invoicing requirements.
• Filament is acceptable, or already present, as the back-office framework.
• You are pre-scale: a handful of plans, straightforward recurrences, and no finance team demanding revenue-recognition-grade reporting.
• Your risk tolerance accommodates a small, single-maintainer package (37 stars) — meaning you are prepared to vendor/fork it and own the code if upstream stalls.

Look elsewhere when:

• You need a vendor with an SLA, security review artifacts, or a support contract — this is community OSS with no such guarantees.
• Billing is core differentiation (usage metering, complex proration, tax/VAT handling, multi-currency) — use Stripe Billing directly, or a dedicated platform such as Chargebee/Recurly, and keep the domain in-house.
• The stack is not Laravel/Filament, or you intend to move off Cashier.
• You operate in a regulated or audited environment where an unvetted dependency touching payment state is a non-starter.
• You need guaranteed upgrade paths — check the release cadence, changelog discipline, open-issue responsiveness, and test coverage before treating the 2026-10-06 release as a sign of sustained maintenance.

How to Pitch It (Stakeholders)

For executives: We can compress subscription billing from a multi-week build into days. This package supplies the subscription management layer and an internal admin UI on top of Stripe — infrastructure we would otherwise pay engineers to write from scratch, and which creates no customer-facing differentiation. It is MIT-licensed, so there is no license cost and no lock-in beyond Stripe itself. The trade-off is maturity: it is a young, small-audience open-source project, so we should plan to fork and own the relevant code rather than depend on it long-term. Net: lower cost and faster time-to-first-revenue, with a modest maintenance contingency.

For engineering: It layers a Filament admin UI over Laravel Cashier’s Stripe integration, which means we inherit Cashier’s webhook and sync model rather than a parallel one — that is the main reason it is low-risk to evaluate. It removes the boring parts (plan records, subscription state screens, admin actions) and leaves the interesting parts (pricing model, entitlements, dunning) to us. Two caveats to size: it constrains us to Stripe-only and Filament, and with ~37 stars we should assume bus-factor risk — pin the version, read the source before adopting, and be ready to vendor it. Recommended next step: a short timeboxed spike to verify it covers our plan/upgrade flows, then a fork-and-own decision documented in the ADR.