Saas Provider Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy framing for SaaS scaffolding. The bundle sits in the "tenant/plan/subscription plumbing" layer of a SaaS — the part every product team rebuilds. Its real value to a PM is as a scope reference: it enumerates the concerns (provider/tenant model, plan tiers, subscription lifecycle, provisioning) that a build estimate must account for, rather than as a dependency you'd ship.
• Multi-tenant architecture direction. Use it to pressure-test whether your roadmap assumes single-tenant-per-customer (simpler, cheaper, easier to sell to enterprises) or true multi-tenancy (shared schema, tenant resolution, per-tenant config). This is a decision that gets expensive to reverse after the first enterprise contract.
• Monetization feature sequencing. Plan tiers, entitlements, upgrade/downgrade flows, and trial handling are roadmap items that touch billing, auth, and data model simultaneously. A package like this forces the conversation early instead of in a "we need plans by Q4" scramble.
• Buy-side diligence on adjacent options. The evaluation itself is a useful artifact: it clarifies that the mature options live in the Laravel/Stripe ecosystem (Cashier-style subscription abstractions, established multi-tenancy libraries) and that the Symfony side has thinner, less-maintained equivalents — a real input to framework choice if SaaS billing is core to the product.
• Not supported: a ship decision. With 1 GitHub star, 0 dependents, and a last release in July 2022, this cannot be a dependency in anything with a revenue path. Treat it as a prior-art / reference-reading task (1–2 engineer-days), not a procurement.

When to Consider This Package

Consider it only as reading material, and only when all of the following hold:

• Your stack is Symfony (the package is a Symfony bundle — it will not drop into Laravel; that mismatch alone disqualifies it for any Laravel codebase).
• You are at the architecture-decision stage for multi-tenancy or subscription tiers and want a small, readable example of how one team modeled it.
• The team is comfortable vendoring or re-implementing rather than depending — i.e., you would copy patterns, not composer require it.
• Your PHP/Symfony version is pinned to whatever this targets (2022-era Symfony), which will not be true of any greenfield project started today.

Look elsewhere — or build — if any of these apply:

• You need maintained code. No releases since 2022, one star, zero dependents means: no security patches, no compatibility updates, no issue triage, and no one to ask when it breaks. The bus factor is effectively zero.
• You are on Laravel. Use the framework-native path: Laravel Cashier (or an equivalent billing abstraction) plus a mature multi-tenancy package. This bundle is not a candidate.
• Billing and entitlements are core revenue. Payments, proration, dunning, tax, and invoicing are domains where buying from a maintained vendor (Stripe Billing, Paddle, Chargebee) beats both building and adopting an unmaintained MIT bundle.
• You need SOC 2 / audit-friendly dependencies. A single-maintainer, two-year-stale bundle will not survive a vendor review, and you'll spend more explaining it than replacing it.
• You need enterprise tenancy guarantees (data isolation, per-tenant encryption, noisy-neighbor controls) — that's a bespoke build or a commercial platform.

How to Pitch It (Stakeholders)

To executives: We evaluated an open-source Symfony SaaS scaffold as a potential shortcut for tenant and subscription plumbing. The recommendation is do not adopt — it has one star, no downstream users, and hasn't shipped since mid-2022, which makes it an unmaintained dependency in a revenue-critical path. Instead, we'll spend a small amount of engineering time reading it as a design reference to sharpen our own build estimate. Net cost is near zero; the benefit is a better-scoped plan and a documented rationale for building rather than adopting.

To engineering: This is a Symfony bundle, not Laravel — so it's out of scope for our stack, and even on Symfony it's a 2022 artifact with no maintainer. Don't add it to composer.json. Do skim it for how it structures provider/tenant and plan/subscription entities, capture anything worth stealing, and fold that into the design doc. For the Laravel path, benchmark against Cashier plus a maintained tenancy package before we commit to a build. Include a one-paragraph "alternatives considered" in the ADR so the next team doesn't re-litigate this.