Pontus Laravel Package

Product Decisions This Supports

• The build-vs-buy call for billing primitives. Subscriptions, plans, invoices, and feature entitlements are table stakes for nearly every SaaS product, and every team eventually faces the same fork in the road: compose them from packages, adopt the payment provider's native billing model (Stripe Billing, Paddle, Lemon Squeezy), or build a thin first-party layer. Pontus is one input to that decision — specifically the "reuse what exists" branch — not the answer itself.
• Framing the admin surface vs. the money surface. What Pontus actually appears to supply is a Filament back office over plan/subscription/invoice/entitlement records. That is directly useful if the near-term need is support tooling — "let me look up a customer's plan and invoice status." It is not useful for moving money and reconciling it. Separating those two needs into distinct roadmap items is itself a valuable decision, and this package forces the question.
• A pricing and packaging modeling artifact. The plans → subscriptions → invoices → features-entitlements shape is a reusable design input for stakeholder conversations about tiers, entitlements, and upgrade paths — regardless of whether any code ships. Even a rejected package can pay for itself by seeding a schema discussion.
• Prototyping and internal-tooling scope. For a demo environment or an internal prototype to pressure-test a pricing model, the cost of a half-day spike is trivially small relative to the speed of getting something clickable in front of stakeholders.
• Roadmap signal: none. The project is archived. There is no forward-looking signal to plan features, headcount, or timelines against. This should be recorded as a "frozen, do not plan around" item, not as a dependency with a trajectory.
• Dependency-register hygiene. Adding this to the dependency register flagged unmaintained is a cheap PM action that converts a future surprise (a Filament upgrade breaking billing screens) into a known, scheduled follow-up.

When to Consider This Package

Consider it when:

• You are already on Laravel + Filament 4 and want plan/subscription/invoice/feature CRUD in a panel with minimal ceremony, matching the Lara Zeus idiom your team already knows.
• The need is internal and administrative — support lookups, back-office prototyping, a demo — not customer-facing revenue handling.
• You are prepared to own the code from day one. MIT plus archived status means the realistic adoption model is fork-and-own: pin an exact version, commit the lockfile, assign an internal owner, and budget for reading and patching the source.
• The domain model is the deliverable. If one plausible schema saves a week of design debate, that is a legitimate return even if you reimplement it later as first-party Filament resources.
• You can timebox a spike (roughly half a day to a day) to confirm what tables it migrates, what views and config it publishes, and whether the advertised features actually function under Filament 4 rather than merely resolving in Composer.

Look elsewhere when:

• The workflow is load-bearing for revenue — checkout, proration, dunning, tax, customer-facing invoices, entitlement enforcement. An archived, single-maintainer, zero-dependent package is the wrong risk profile for anything touching money. Use the payment provider's billing engine as the system of record.
• You need support, SLAs, security patching, or a predictable cadence. None exist, and archiving removes even the informal expectation of a fix.
• You are on Filament 3. The v2 line targets Filament 4; adopting bundles a framework major upgrade into a billing decision, coupling two unrelated risks.
• You need compliance-relevant behavior — audit trails, PCI scope, tax jurisdiction logic, GDPR deletion semantics for billing records. You will write and defend all of that yourself.
• You would be the first production dependent. With zero dependents and a recent archive, there is no evidence these paths have run at scale anywhere.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Laravel package offering ready-made admin screens for plans, subscriptions, invoices, and feature flags. It is worth knowing about because it can compress "we have a demonstrable billing model" from weeks to days — for internal and prototype use. It is not worth betting the revenue path on: the project is archived, has a single maintainer, no production adopters we can point to, and its latest release only adjusts a framework version constraint. Recommendation: use it as a design reference and prototyping accelerator, budgeted as a timeboxed spike, with the explicit assumption that we own — and may replace — the code. Real billing capability should be bought from our payment provider or a supported vendor.

To engineering: Treat this as a fork, not a dependency. Archiving means no upstream fixes, no security patches, and no compatibility work after the 2.0.1 constraint bump. If we proceed: pin an exact version and commit the lockfile; verify with a throwaway install that Filament 4 support is functional rather than merely declarative; enumerate every table migrated and every view/config published so we know exactly what we now own; keep overrides minimal so a future reimplementation is a port rather than an archaeology project; and write the exit path down — most likely reimplementing the admin resources directly in Filament, a bounded piece of work at this scope. Register it as unmaintained so the next Filament upgrade surfaces it as a known follow-up.

To product: Do not let this enter the roadmap as a dependency. Its value is the domain vocabulary and a fast way to pressure-test a pricing and entitlement model with stakeholders before committing to a real billing integration. Scope any exploration as a written go/no-go spike, with the default outcome "we learned the model and built it ourselves" rather than "we shipped on an archived package."