Laravel Core Laravel Package

Product Decisions This Supports

• Build-vs-buy for the undifferentiated 60%. This package is essentially a pre-built SaaS/e-commerce chassis: multi-guard auth (Sanctum-backed users + admins), subscription billing via Cashier, cart/checkout, 20+ payment processors, RBAC, wallet/credits, multi-currency, blog/CMS, and 60+ report types. The strategic question it answers is "do we spend two quarters on plumbing or one on differentiation?" — and it lets you model the first option with real numbers instead of estimates.
• Monetization and packaging design. Plan + Feature + usage counters (hasFeature(), useFeature(), featureUsage()) plus scheduled reset:subscriptions-usages is a ready-made substrate for tiered pricing, seat/usage limits, trials, grace periods, and promo codes. This is the piece that most directly informs pricing-page and plan-catalog decisions — you can prototype a packaging model in days.
• Payments and geography roadmap. A PaymentProcessorInterface with an AbstractPaymentProcessor base, 11 concrete processors, mapper classes for webhook normalization, and a uniform PaymentResult/RefundResult contract means "add a new gateway" becomes a scoped, estimable unit of work rather than a research spike. That de-risks decisions like "do we support PayPal/Stripe/local rails at launch or in v2?"
• International expansion sequencing. Currency::resolve($address) + CURRENCY_AUTO_DETECT + scheduled update:exchange-rates gives you a concrete answer to "can we launch in EU/APAC without a pricing re-architecture?" — testable before committing.
• Admin/back-office scope. RBAC via Module → Permission → Group, plus admin endpoints for customers, orders, subscriptions, coupons, payment methods, and reports, defines a default internal-tooling baseline. This is a strong input to "buy the back office, build the customer experience."
• Analytics and reporting build-vs-buy. ReportService with 60+ registered report types and CSV export, plus MetricsCalculator, is the strongest single argument for the package — reporting is chronically underestimated and rarely differentiating.
• Roadmap sequencing / MVP scoping. The opt-out toggles (ignoreRoutes(), withoutCart(), ignoreMigrations()) and model-binding (useUserModel(), useSubscriptionModel()) let you scope an MVP by subtraction: take auth + billing + admin, defer shop/wallet/blog. Useful for phase-gating a launch.
• Operational readiness checklist. The shipped artisan commands (abandoned-checkout processing, expired-report cleanup, subscription renewal/grace/expiry sweeps, exchange-rate refresh) double as a checklist of operational decisions you'd otherwise discover in production.

When to Consider This Package

Consider it when:

• You are building a Laravel monolith SaaS or e-commerce product and the 12–24 month scope genuinely includes subscriptions, payments, admin RBAC, and reporting.
• You are an agency or product studio shipping multiple similar Laravel properties and want a shared, forkable baseline.
• Your team is comfortable owning vendor-style code: reading 61 models and 39 traits, forking, and accepting maintenance.
• You need breadth over depth fast — breadth here is real (payments, multi-currency, wallet, CMS, reports).
• You can adopt it incrementally via the opt-out toggles rather than as an all-or-nothing framework.
• You plan to stay on Laravel and accept Cashier/Sanctum as your billing/auth substrate.

Look elsewhere when — and this matters more than the above:

• You need community validation or third-party support. Zero stars, zero dependents, single maintainer. That is a bus-factor-1 dependency on the critical path of revenue (auth + payments). There is no ecosystem to lean on, no Stack Overflow corpus, no security-review precedent.
• You need vendor SLAs, SOC 2-style assurance, or a formal security review. Nothing in the metadata indicates this exists. Payments and PII auth are exactly where you can least afford unvetted dependencies.
• The package metadata itself is a red flag. An MIT license is good; a "last release" dated in the future signals release/metadata hygiene worth verifying before you trust versioning. Treat the SKILL.md as vendor-supplied marketing until your engineers confirm it against source.
• You want a headless/API-first architecture with independent frontend velocity. The package assumes a cohesive Laravel app with /user/* SPA and /admin/* routes — it's opinionated about shape, not just features.
• Your payments path is regulated, high-volume, or dispute-heavy. 20+ gateway integrations is impressive breadth but breadth ≠ depth. Reconciliation, partial refunds, SCA/3DS, tax, and dunning need a code-level audit before you rely on them.
• You need a narrow, well-maintained dependency. For just subscriptions, use Cashier directly; for just RBAC, use spatie/laravel-permission; for just media, use spatie/laravel-medialibrary. This package's value proposition is the integration, so it's overkill if you only need one slice.

Recommended gate before adoption: a two-week timeboxed spike that (1) audits the payment processors and webhook handling, (2) confirms the reporting layer's actual coverage vs. the claimed 60+, (3) verifies migration/upgrade safety, and (4) produces a written fork-and-own plan with a maintenance owner.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: This is a pre-built Laravel foundation for subscription and e-commerce products: login and admin accounts, recurring billing, shopping cart, payment gateways, permissions, multi-currency, reporting, and content management. Adopting it could compress the commodity portion of our build — realistically the first several months — and let us spend that time on what customers actually pay us for. The honest caveat is maturity: it has essentially no external users, one maintainer, and no third-party support. So the recommendation is not "buy" but "evaluate with our eyes open": a short, bounded technical audit, after which we either adopt it as an internal fork we own outright (MIT-licensed, so that's permitted) or walk away having lost two weeks. The upside is schedule; the risk is concentrated in the payment and authentication code, which is precisely what the audit targets.

For engineering — the one-paragraph version: It's an opinionated Laravel package: Coderstm static facade plus Blog/Shop/Currency facades, four service providers, 39 model traits, 61 Eloquent models, a PaymentProcessorInterface with an AbstractPaymentProcessor base and 11 concrete processors (plus webhook mappers), Sanctum-backed users/admins guards, and DB-overridable config through ConfigLoader/AppSetting. It ships artisan commands for subscription lifecycle and abandoned checkouts, and middleware for guard resolution, currency, and cart tokens. The design is defensible — interfaces over concretes, model binding via Coderstm::useUserModel(), event-driven side effects, opt-out toggles so we can adopt in slices. Three concerns: it's a bus-factor-1 dependency with no community; it's broadly coupled (auth + payments + CMS + reporting in one package), so a fork means owning all of it; and breadth in payment gateways does not imply depth in reconciliation, refunds, or 3DS. Plan: audit payments and auth first, verify upgrade/migration safety, then decide fork-and-own vs. compose-from-narrower-packages. Do not adopt as an unmodified upstream dependency on the revenue path.

For the product/eng joint decision: the real question isn't "is this package good" but "do we want to own a SaaS chassis in-house?" If yes, this is a legitimate head start and a credible fork candidate. If we want to stay on maintained infrastructure, the alternative is assembling Cashier + Sanctum + a permissions package + a payments provider, which costs more schedule but far less ownership risk. Frame the decision in those terms.