Spike Laravel Package

Product Decisions This Supports

• Build vs. buy for recurring revenue. Billing is a deceptively deep surface — proration, dunning, SCA/3DS, tax, invoice PDFs, plan changes, trial-to-paid conversion. Spike lets you buy 80% of that for a Laravel codebase and spend engineering cycles on the product instead. The decision this informs: do we staff a billing squad, or do we rent one?
• Monetization roadmap sequencing. Whether you can ship a pricing page, self-serve upgrades, trials, and a customer billing portal in the current quarter or the next one. If a paid tier is gating revenue, the time-to-first-invoice matters more than architectural purity.
• Pricing model flexibility. Support for subscriptions and plan tiers determines whether you can test seat-based vs. flat vs. tiered pricing without a re-architecture. Usage-based/metered pricing is where you should check scope carefully before committing a roadmap to it.
• Freemium and packaging strategy. The free core alongside a commercial tier is itself a product signal: you can scope an MVP on the MIT core, then budget the paid upgrade as a known line item rather than a surprise.
• Gateway concentration risk. Choosing a Stripe-centric package is a de facto decision to concentrate payments on Stripe — relevant to finance, treasury, and international expansion planning.
• Scope boundary for in-house work. Even if you adopt it, you'll still own entitlements/feature-gating, revenue recognition, refunds policy, and the admin/support tooling around it. Spike draws that line for you; make sure you agree with where it lands.

When to Consider This Package

Adopt when most of these are true:

• Your app is Laravel, and your team is small enough that a billing subsystem is a genuine opportunity cost.
• You're Stripe-first (or willing to be) and predominantly subscription-based, sold self-serve.
• You need to get to first revenue quickly and can tolerate a young dependency in a reversible layer — billing logic wrapped behind your own interface so it can be swapped.
• The free MIT core covers your near-term feature set, and the paid tier is a plausible future purchase rather than an immediate requirement.

Look elsewhere when any of these are true:

• Ecosystem validation matters to you. 30 stars and zero dependents means essentially no third-party production mileage to learn from. You will be an early adopter, and early adopters find the edge cases.
• You need multi-gateway support — Paddle, Lemon Squeezy, Adyen, regional processors — or expect to switch gateways as you expand.
• Complex billing is core to the business: usage metering at scale, committed-spend contracts, multi-currency with localized tax, PO/net-30 enterprise invoicing, revenue recognition and audit requirements. These are where thin wrappers buckle.
• You need contractual maintenance guarantees. A single-maintainer package with a commercial upsell introduces key-person risk that procurement and finance will flag.
• You're not on Laravel, or you're on a Laravel version the package doesn't track closely.
• Billing is a competitive differentiator rather than a commodity — then owning it may be worth the cost.

Recommended posture: a two-week, timeboxed spike behind an internal BillingProvider interface, with an explicit exit cost estimate. Treat the decision as reversible only if you insulate the rest of the codebase from it on day one.

How to Pitch It (Stakeholders)

To executives: Recurring billing is a commodity we should rent, not build. Spike is a Laravel-native package that gives us subscriptions, plan management, and customer billing flows without a dedicated billing team — potentially weeks of engineering saved per quarter. It's MIT-licensed, so the financial commitment to evaluate is near zero, and the paid tier is a bounded, optional cost we can model before committing.

The honest caveat, stated up front: this is an early-stage package — small community, no meaningful third-party adoption, effectively one maintainer, and a commercial model layered on the free core. That's an acceptable risk for a swappable layer and an unacceptable one for a core system. Our mitigation: contract the integration behind our own interface, keep gateway access in our own Stripe account, and timebox evaluation with a defined exit.

To engineering: It's a Laravel package, so integration cost is low and idiomatic. The ask is that we treat it as an implementation detail — no billing concepts leaking into domain code, our own webhooks and entitlement checks, and a documented path to replace it. If the abstraction holds, adopting it is cheap and so is leaving.

To finance/legal: Payments settle into our own processor account; the package is orchestration, not a payment intermediary. Confirm the MIT scope for the free core versus the paid tier's terms before we build a roadmap assumption on either — and confirm who owns tax and revenue-recognition obligations, because the package almost certainly does not.