Spark Laravel Package

Technical Evaluation

Architecture fit — poor for new work, narrow fit for legacy upkeep. Spark is not a composable library; it is an opinionated application scaffold. spark:install injects routes, controllers, Blade/Vue views, migrations, and config into the host app and then expects to own authentication, subscription billing, team/seat management, invoices, and the user dashboard. It fits exactly one shape: a greenfield Laravel 5.x monolith selling seat-based SaaS subscriptions through Stripe, Braintree, or Paddle. It does not fit API-first/headless products, existing domain-heavy applications, custom multi-tenancy, usage-based or metered billing, or non-supported payment providers. The 419 stars are misleading — the public repo is a thin installer stub; the substantive code ships through a private Composer repository gated on a paid license.

Integration feasibility — gated by licensing, not by code. Installation requires license credentials in auth.json/composer.json to resolve the private repo. Spark was retired as a commercial product, so license acquisition for a new project is effectively impossible; even existing licensees face an unmaintained private channel. Any CI/CD pipeline must hold and rotate those credentials, which is an audit and secret-management burden most teams will not want. The realistic integration posture is "preserve an existing install," not "adopt."

Technical risk — high, with several hard blockers.

• Runtime EOL: last release 2018-01-01, targeting the Laravel 5.x line and PHP 7.1–7.3. No PHP 8.x support, and upstream Laravel 5.x no longer receives security fixes. That is a compliance problem for SOC 2 / PCI DSS regardless of code quality.
• Payments drift: the bundled Cashier predates Payment Intents, SCA/3DS2 (mandatory in the EU since 2019), and modern webhook semantics. Running it against today's Stripe API ranges from fragile to non-functional; API version pinning buys time, not safety.
• Front-end rot: Vue 2 (EOL Dec 2023), Bootstrap 4, Laravel Mix with webpack 3/4 and node-sass — builds fail on modern Node/OpenSSL before you touch a line of PHP.
• License restrictions: verify whether forking and patching is permitted before assuming you can self-maintain.

Key questions for the sponsoring team:

1. Do we already hold a valid Spark license, and is the private repository still reachable today? (If no, this evaluation ends.)
2. What Laravel and PHP versions must the product run on for the next 24 months?
3. Which payment provider, and do we need SCA/3DS2, Payment Intents, local payment methods, or tax handling?
4. Do we actually need teams/seats, or is single-user subscription billing sufficient (which Cashier alone covers)?
5. Is the Spark Vue SPA retained, or is it being replaced by Inertia/Livewire anyway?
6. What is our appetite for an indefinite self-maintained fork?

Integration Approach

Stack fit. Spark assumes Laravel 5.5–5.8-era, PHP 7.1–7.3, MySQL/Postgres, Redis, Stripe/Braintree/Paddle, Vue 2 + Bootstrap 4, and Mix. Every one of those is a mismatch against a current Laravel 11/12, PHP 8.3, Vite, Inertia/Livewire, Cashier v15 baseline. Treat the dependency graph as frozen and the rest of the app as the thing that must be isolated from it.

Recommended migration path — treat Spark as a specification, not a dependency. The valuable artifact in Spark is its billing state machine (plans, coupons, trials, proration, seat quantity changes, invoice history, team roles), not its source. Re-implement that surface on Jetstream or Breeze + Cashier + Fortify, with team membership and seat entitlements expressed as policies and a small entitlement service. This removes the license gate, the EOL runtime, and the front-end rot in one move, and it is the only path that results in a supportable product.

If Spark must run in the interim. Pin the whole thing into a container: PHP 7.3, Node 14, Composer with the license repo baked into a private artifact registry so builds don't depend on a live credential. Put it behind its own subdomain or path prefix with an isolated session cookie, do not let new code depend on Spark internals, and add an anti-corruption layer (a thin billing service interface) so replacement is a swap rather than a rewrite. Mirror the private repo to internal storage — the highest-probability failure is the channel disappearing mid-migration, not a code defect.

Compatibility and sequencing.

1. Discovery (1 week): license verification, repo reachability, mirror to internal registry, dependency audit.
2. Spike (1–2 weeks): clean install in a throwaway branch, run the suite, exercise a real Stripe test-mode subscription end to end, confirm which API version still works.
3. Data model diff: map Spark tables (users, teams, team_users, subscriptions, team_subscriptions, Cashier invoice/receipt tables) against the target schema; identify what must be preserved for billing history and audit.
4. Parity checklist: enumerate every plan, coupon, trial rule, proration behavior, webhook handler, and invoice/PDF path. This checklist is the acceptance criteria for the replacement.
5. Build replacement: Cashier + teams + entitlement service, running in parallel against the same Stripe test account.
6. Dual-run and backfill: shadow-read the new entitlement service against production traffic before cutover.
7. Cutover and decommission: switch webhook endpoints, backfill subscription records, retire the legacy container.

Operational Impact

Maintenance. Effectively self-maintained in perpetuity. Every Laravel, PHP, Stripe, and Node upgrade becomes a manual patch against code you did not write and cannot easily diff against upstream. Budget 0.25–0.5 FTE indefinitely for the legacy stack — and note that this FTE buys stability, not features. The unpatched Laravel 5.x dependency is the single largest ongoing risk and is not solvable by effort alone; it requires migration.

Support. No vendor. The product is retired and the paid Spark forum is largely dormant. Community answers on Stack Overflow are years stale and frequently describe a different major version. There is no CVE feed, no security contact, and no upgrade guide. Internal documentation of the billing state machine must be written from the source before any engineer leaves the team.

Scaling. Spark is not the bottleneck — it is an ordinary Laravel monolith. Horizontal scaling works with shared Redis sessions/cache and dedicated queue workers. Two real concerns: Stripe webhook handling must be queued and idempotent (Spark's defaults are close to synchronous and will buckle under retry storms), and seat/entitlement checks computed per request become a hot path under load — cache them with explicit invalidation on subscription change.

Failure modes, ranked by likelihood × impact.

1. Silent webhook failure → entitlement drift. Failed payments or cancellations never propagate; users retain access after churn. Needs a reconciliation job comparing Stripe state to local state nightly.
2. Private repo unavailability. Builds stop resolving; hotfixes become impossible. Mitigated only by internal mirroring.
3. Stripe API version sunset. A pinned API version is retired and every billing call hard-fails at once, with no patch path.
4. SCA/3DS2 declines. EU/UK renewals fail at the authentication step, producing involuntary churn that looks like customer behavior rather than a bug.
5. Unpatched framework RCE. Laravel 5.x has no security backport channel.
6. Toolchain rot. CI breaks on Node/OpenSSL updates before code does.

Ramp-up. Onboarding cost is high and non-obvious. New engineers have no current documentation, no upstream to read, and an unfamiliar Vue 2 SPA bolted onto a Laravel version they have likely never worked in. The first task for any new owner should be writing the billing state machine down — not changing code.

Bottom line for the product decision. Score 2.255 accurately reflects a retired commercial scaffold that is technically and contractually hard to adopt. Do not select laravel/spark for new work under any circumstances. For an existing installation, treat the Spark surface as a frozen legacy subsystem, fund a Cashier-based replacement within two quarters, and pre-commit to the migration before the license channel or the pinned Stripe API version fails on its own schedule.