Bundle Features Laravel Package

Product Decisions This Supports

• Feature gating and plan-tier packaging — the bundle models "features" and "plans" as first-class concepts, so it directly supports decisions about which capabilities sit behind which tier (Free/Pro/Enterprise), how entitlements are checked at runtime, and how you grandfather or sunset a feature without shipping new code.
• Build vs. buy for entitlement infrastructure — when a roadmap item reads "gate X behind paid plan," the default engineering instinct is to hand-roll a features table, a pivot to plans, and a can() helper. This package is a reference implementation of that slice; the PM decision is whether entitlement logic is core differentiation (build, own it) or undifferentiated plumbing (buy/borrow, keep it boring).
• Pricing and packaging experiments — plan definitions being data rather than code is what makes a pricing test cheap: change the plan-to-feature mapping, measure conversion, revert. If gating logic is hardcoded, every pricing experiment becomes an engineering ticket, which is the real cost being weighed here.
• Roadmap sequencing for monetization work — a package that already answers "what does plan N include" lets you schedule billing/packaging milestones earlier, because you're not first spending a sprint on the entitlement substrate.
• Sales-led customization (enterprise deals) — per-account feature overrides are a recurring ask once you have a handful of large customers. A plan/feature model that supports overrides is an enabler for a sales-assisted motion; without it, every bespoke contract becomes a branch in application code.

When to Consider This Package

Consider it when all of the following hold:

• The stack is Symfony (this is a Symfony bundle, not Laravel — a Laravel codebase would need a shim or a reimplementation, which erases most of the "buy" advantage and should be treated as a build decision instead).
• You need coarse-grained, plan-level gating — "is this workspace on a plan that includes exports?" — rather than per-user percentage rollouts, experimentation, or fine-grained audience targeting.
• Your plans and features change often enough that config-over-code has measurable value, or you expect to run several packaging/pricing iterations in the next two quarters.
• You are early enough that a small, opinionated data model is cheaper than integrating a full commercial platform, and you're willing to own the schema and migrations as the product grows.
• You're comfortable treating it as a starting point to fork or vendor, not a long-term dependency you'll never touch.

Look elsewhere when:

• Stack mismatch — Laravel or framework-agnostic requirements.
• Maturity and support risk matter. At ~11 stars, zero dependents, and a single maintainer, this is unproven in production. There is no meaningful ecosystem answer if the maintainer stops. If feature gating is on the critical path for revenue (billing enforcement), a package with no dependents is a poor place to put your paywall.
• You need progressive delivery semantics — percentage rollouts, kill switches with metrics, experiment assignment, audit trails for who flipped what. That's a different product category (LaunchDarkly/Unleash/Flagsmith); this bundle is packaging-focused, not delivery-focused.
• Compliance or procurement requires a vendor with an SLA, SOC 2, or a support contract.
• Your entitlement model is already complex (usage-based metering, seat counting, per-API-call quotas). A simple plan-feature pivot will buckle; you need metering and rating, not a boolean lookup.

How to Pitch It (Stakeholders)

For executives: We have a recurring need to sell different levels of the product without shipping different versions of the product. That means plan-to-feature mapping has to live in configuration, not in code, or every pricing change becomes an engineering project. There's a small MIT-licensed open-source component that already models features and plans. The strategic value isn't the code — it's that it forces the entitlement conversation now, before billing work starts, and lets us run packaging experiments in days instead of sprints. The risk is maturity: the project is tiny and effectively unmaintained-by-committee, so I'd recommend we treat it as a design reference we vendor, not a dependency we rely on. Cost of adopting the pattern is low; cost of discovering mid-quarter that our paywall rests on an abandoned repo is high.

For engineering: This is a Symfony bundle with a features/plans data model — a shortcut past the "should features be rows or enum cases?" debate. Two caveats before anyone writes an import: it's Symfony, so a Laravel codebase inherits a port rather than an integration; and with ~11 stars and zero dependents, there's no community safety net, so budget for reading the source and owning the migrations. My recommendation is to use it as a specification — mirror the schema and the plan-feature check API — and only take the hard dependency if the team explicitly accepts ownership of a fork. If we need percentage rollouts or experiment assignment, that's a separate tool and a separate decision; this shouldn't be stretched to cover it.

Bottom line: low-risk to learn from, high-risk to depend on. Adopt the pattern, defer the package.