Filament Subscriptions Laravel Package

Technical Evaluation

Architecture fit. This is a Filament panel plugin layered over laravelcm/laravel-subscriptions 1.8, and the responsibility split is the one a TPM should want: the domain engine owns plans, features, subscriptions, and recurring periods; this package supplies Filament resources, pages, billing UI, widgets, translations, and install scaffolding. We are adopting an admin surface, not a second billing engine. Two boundaries must be stated up front because they define scope. First, there is no headless billing API and no payment-provider abstraction — this is in-panel administration, not a payments platform, so Stripe Billing/Paddle-style scope stays out of the package. Second, the plugin assumes plans and features are the system of record for entitlements; if entitlements also live in a feature-flag service, CRM, or warehouse, we are buying a reconciliation project and should decide that deliberately rather than discover it in QA.

The defining constraint is major-version lockstep with Filament. v5.0.0 targets Filament v5 and explicitly routes Filament v3 users to a 1.x / v3 branch. The plugin's major tracks the UI framework's major, not its own semantics, so our panel upgrade cadence is this dependency's cadence. It can never be the reason we upgrade, and it must never be the reason we cannot.

Integration feasibility. Feasible for teams already on Laravel 12 / PHP 8.2+ / Filament v5. Two prerequisites land together and neither is optional: Filament v5 and laravelcm/laravel-subscriptions 1.8. The install-command fix — migrating before creating the main plan — removes an ordering assumption that made first-run setup fragile and directly de-risks automated provisioning (CI seeds, container init, preview environments, fresh-tenant bootstrap). That is a reportable delivery-risk reduction, not a changelog footnote. The billing page now honoring configured subscription models and resolving panel URLs/redirects (#20) means we are not forced onto library defaults and can wire it behind our actual panel path.

Technical risk.

• Major-version lockstep (high). No supported mixed-version configuration. A panel upgrade becomes all-or-nothing with this plugin on the critical path.
• Branch-based prior-major support (medium). Filament v3 users are served from a branch, not a maintained release line. Branch-only maintenance is a weak signal; do not assume backports.
• Removed cancels_at column (medium). Renewal no longer writes it. Any report, export, dashboard, or downstream integration reading it must be found and retired. Open question: does the migration drop the column or leave it orphaned? An orphaned column returning stale data fails silently — worse than a hard error.
• Translation auto-fill (low severity, user-visible). Plan/feature edits now populate every translation. Good for consistency, but partial translation is no longer possible; locales deliberately left blank will carry the source-language string. This changes the demo and the content-ops workflow.
• Positive signals. URL/redirect fixes landed, billing page respects configured models, a stated full test suite, and an outside contributor credited — healthy signals for a 64-star project.

Key questions.

1. Is cancels_at dropped by migration or orphaned, and what is the remediation path for existing rows?
2. Does translation auto-fill overwrite non-empty translations, or only populate empties?
3. Is Laravel 13 actually in the tested matrix, or only permitted by composer.json?
4. What is the support commitment for the v3 / 1.x branch — security fixes, or de facto end-of-life?
5. Does billing-page URL resolution hold behind a non-default panel path, subdomain tenancy, or a reverse proxy with a path prefix?
6. Which Filament v5 minors are supported, and how fast are patches cut when Filament ships a breaking minor?
7. Who owns the subscription domain internally, and do we have a local-patch path if upstream stalls?

Integration Approach

Stack fit. Best fit: Laravel 12, PHP 8.2+, Filament v5, laravelcm/laravel-subscriptions 1.8, single-tenant or straightforward multi-tenant admin. Poor fit: Filament v3 or v4, Laravel 10/11, PHP 8.1, a different subscription engine, or any architecture where billing administration is a standalone service rather than a panel concern. One structural assumption to surface in the design review: the plugin treats the plan/feature/subscription schema as the source of truth, so an external entitlement store is a reconciliation project, not an integration detail.

Migration path. Cheapest at the start of a panel build, before bespoke billing screens exist; adopting later means retiring custom CRUD, which usually costs more than the head start saves. For existing installations, land Filament v5 first, then take this package — v5.0.0 is not a supported target for v4. If we are on Filament v3 today, the real decision is whether to fund a v3→v5 panel migration at all. This package is a passenger in that decision, never the driver, and it should not appear in the business case as a reason to move.

Compatibility. Pin exact versions of Filament, this package, and the subscriptions library together; avoid caret ranges on all three. Bump this package and the library in the same commit, never one without the other. Treat Laravel 13 as unproven until we exercise it in our own matrix. Verify the billing page behind our real panel path, proxy, and tenancy setup rather than assuming the default.

Sequencing.

1. Confirm prerequisites and pin versions; run install/migrate against a production-shaped database, not a fresh schema.
2. Inventory every consumer of cancels_at (reports, exports, dashboards, BI extracts) and retire them before or with the upgrade.
3. Run the install command end-to-end in a throwaway environment to validate provisioning and the plan-creation ordering fix.
4. Land as an isolated dependency upgrade — the column removal and translation auto-fill are silent behavior changes that are hard to attribute inside a large release.
5. Spot-check every locale after a plan edit, and confirm the billing page behind the real panel URL, proxy, and tenancy config.
6. Only then open plan/feature editing to non-engineering admins.

Operational Impact

Maintenance. Budget this as a recurring line item tied to Filament's release cadence, not a one-time integration. Every Filament major forces a coordinated bump of Filament + this package + laravelcm/laravel-subscriptions, with no supported mixed-version state. Plan one upgrade workstream per Filament major and expect a small number of patch-level follow-ups whenever Filament ships a breaking minor. Single-maintainer risk is real at 64 stars and zero dependents: assign one named engineer as owner of the subscription domain, and decide in advance whether we will fork and locally patch or wait on upstream. Waiting is acceptable for cosmetic issues; it is not acceptable for security fixes on a billing-adjacent surface.

Support. Internal support load splits in two, and both tickets should route to the same owner. Admin-user questions ("why can't I blank this locale?", "where did my cancellation date go?") are predictable and answerable with a short internal note; upstream bug reports go to a second tracker with no SLA. Because entitlements are assumed to be plan/feature-driven, support will also absorb any drift between our panel and whatever else claims to know a customer's access level — that is the operational cost of not making the schema authoritative. Set expectations accordingly: this is community-supported MIT software, and the 1.x / v3 branch is not an LTS commitment.

Scaling. Functionally, this scales with the panel: it is admin CRUD and a billing page, so load follows admin concurrency, not end-user traffic — rarely a capacity concern. The real scaling limit is organizational. Feature limits and plan definitions are managed by humans in a UI, with no bulk-edit or API path described, so large catalogues or frequent packaging experiments will feel manual. Multi-tenancy is unverified behind non-default panel paths and proxies, which makes it a scaling question rather than a networking detail: validate before committing to a tenancy model. Multi-language catalogues scale fine in the number of locales but not in nuance, since auto-fill removes intentional gaps.

Failure modes. Ranked by how quietly they fail:

• Stale cancels_at data (silent). If the column is orphaned rather than dropped, reports keep producing plausible wrong answers. Highest-priority pre-flight check.
• Translation overwrite (silent, cosmetic-to-legal). Blank locales inheriting source-language strings is a content defect that surfaces in front of customers, and in some markets is a compliance concern.
• Entitlement drift (silent, business-critical). Two sources of truth for access produce customers who paid and are locked out, or did not pay and are not.
• Billing-page URL breakage (loud). Redirects failing behind a proxy or custom panel path fail visibly, which makes it the easiest to catch — provided we test it in a production-shaped environment.
• Upgrade deadlock (loud, strategic). A Filament security patch we cannot take because this package has not shipped a matching release. This is the one that converts a maintenance line into an incident.

Ramp-up. Engineering effort is modest: install, migrate, pin, and validate — days, not weeks — provided Filament v5 is already landed. The hidden cost is domain ramp-up, not setup: whoever owns this must understand the split between laravelcm/laravel-subscriptions semantics and this plugin's UI behavior, across two upstream trackers with different maintainers and release rhythms. Plan for one owner plus at least one informed backup so knowledge does not centralize. Admin-side ramp-up is near zero — native Filament tables and forms mean existing panel users need no new mental model — but content owners need a short brief on translation auto-fill before the first plan edit, and support needs the cancels_at story straight before the first "where did that field go" ticket.