Charge Laravel Package

Product Decisions This Supports

• Build vs. buy for subscription billing on Statamic. Charge is a thin subscription/billing layer for Statamic sites, so it anchors the comparison between (a) wiring Stripe Billing ourselves, (b) adopting Laravel Cashier directly, or (c) dropping in a CMS-native addon. It is the cheapest "buy" option to evaluate and the fastest to prototype against.
• Roadmap: monetization features for a Statamic-based product. If the roadmap includes gated content, paid memberships, or recurring plans, this package defines the minimum viable surface area (plans, subscriptions, customer portal hand-off) and shows what a CMS-native integration actually costs to own.
• Membership / gated-content feature bets. Typical use cases: paid newsletters, course or resource libraries, member-only entries, tiered access to collections. Useful for sizing whether billing is a one-sprint integration or a quarter-long build.
• Vendor and maintenance posture. With 4 stars, zero dependents, and an archived repository, the real decision it informs is not "adopt or not" but "reference, fork, or ignore." That is a legitimate architectural input.
• Buy-vs-build for adjacent commerce work. Confirms that recurring billing is a solved, commoditized problem best delegated to Stripe/Paddle rather than built in-house; the package's small footprint is evidence of how little bespoke logic is genuinely required.

When to Consider This Package

Consider it when:

• You are already committed to Statamic (v3/v4-era) and want subscription billing without leaving the CMS's control panel.
• Your billing model is simple and Stripe-only: flat recurring plans, a customer portal link, webhook-driven entitlement. No usage-based pricing, no multi-currency tax logic, no dunning workflows of your own.
• You need a reference implementation or a vendored starting point — read the source to learn the Stripe webhook and entitlement patterns, then fork under your own maintenance.
• You are running a timeboxed spike (days, not weeks) to validate willingness-to-pay before investing in a first-class billing build.

Look elsewhere when:

• You need active maintenance, security patching, or vendor support. The repository is archived; there is no upstream to escalate to. That is a hard blocker for anything revenue-critical and long-lived.
• You are not on Statamic, or you are on a Statamic version outside the package's supported range. Use Laravel Cashier or Stripe Billing directly instead — broader ecosystem, active maintenance, better documentation.
• You need multi-gateway support, tax/VAT handling, invoicing, or revenue recognition. Delegate to Stripe Tax / Paddle / Lemon Squeezy rather than a CMS addon.
• You require enterprise procurement artifacts — SOC 2 alignment, SLAs, named maintainers, dependency CVE response. A 4-star archived package will not survive that review.
• Your team would be the only maintainer and lacks bandwidth to own a fork indefinitely. Forking is a real, recurring cost, not a one-time escape hatch.

How to Pitch It (Stakeholders)

For executives: This is a tiny, unmaintained addon that handles Stripe subscriptions inside Statamic. It is not a platform bet and should not be presented as one. The strategic value is informational: it tells us that recurring billing in our stack is a thin integration, not a moat — which means we should buy commodity billing infrastructure (Stripe) and spend our engineering on the differentiated product. Recommendation: no production dependency; a short evaluation is justified only if a Statamic monetization initiative is already on the roadmap.

For engineering: Small, Stripe-coupled, and archived — treat it as a reading reference, not a dependency. Timebox an evaluation to a few days: read the webhook handling, entitlement checks, and plan modeling; then decide between Laravel Cashier, Stripe Billing with a thin in-house adapter, or a vendored fork with a named owner and an upgrade path. If we fork, we own CVE response and Statamic version compatibility indefinitely — that must be accepted explicitly, not discovered later.