Flagception Bundle Laravel Package

Product Decisions This Supports

• Decoupling deploy from release. Constraint-based flags let you ship code dark and turn behavior on per environment, role, IP range, date window, or custom expression — useful for trunk-based development and canary rollouts without maintaining bespoke if scaffolding.
• Progressive delivery and kill switches. Enables staged rollouts (internal → beta cohort → regional → GA) and an operational off-switch for risky third-party integrations or new checkout/pricing paths.
• Segment and entitlement gating. Flags keyed on user attributes (plan tier, tenant, role) support packaging decisions — e.g., gating an enterprise-only capability — without hard-coding plan logic into the domain.
• Roadmap experimentation. Adequate for basic A/B-style exposure control and "measure before committing" bets; not a substitute for a statistics-aware experimentation platform.
• Build vs. buy. This is a "borrow and own" option: MIT-licensed, in-process, no SaaS contract, no flag data leaving your infrastructure. Reasonable when vendor budget, data residency, or procurement friction is the blocker; not reasonable if you need a managed control plane.
• Architecture decisions it informs. Choosing config-driven, in-process flag evaluation over a hosted service implies you accept responsibility for flag hygiene, lifecycle/cleanup, and evaluation caching — plan for that owner and process up front.

When to Consider This Package

Consider it when:

• Your stack is Symfony/PHP (this is a Symfony bundle, not a Laravel package — do not mistake it for one), and you want flags wired into DI, config, and Twig without an external dependency.
• You need rich activation context (role, environment, date, IP, expression language) rather than plain boolean toggles, and you'd otherwise write that targeting logic yourself.
• You require no external network calls at request time, no per-seat SaaS cost, and full control of flag definitions in version-controlled config.
• You can fork and own the code: budget an internal maintainer, pin the version, and review diffs before upgrades.

Look elsewhere when:

• You are on Laravel — evaluate Laravel Pennant or a first-party SDK instead; adapting a Symfony bundle is avoidable integration debt.
• You need experimentation statistics, audit trails, approval workflows, a non-engineer UI, RBAC, or guaranteed uptime/SLA — use LaunchDarkly, Unleash, Flagsmith, or GrowthBook.
• Maturity is a hard requirement. Two stars, zero dependents, and a single-maintainer fork signal an unproven supply chain; treat it as a code sample or internal fork, not a supported dependency on revenue-critical paths.
• You need high-volume evaluation guarantees at scale without validating caching and performance yourself.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, in-house capability to separate "code shipped" from "feature enabled," which reduces release risk and lets us stage rollouts by customer segment and turn features off instantly if something breaks. It carries no license fee and keeps flag data inside our infrastructure. The trade-off is maturity: the project is small and effectively unmaintained upstream, so adopting it means we own a fork and assign an engineer as steward. Recommend a time-boxed pilot on a non-critical surface, not a platform-wide commitment.

For engineering: MIT-licensed Symfony bundle providing a feature manager with config-defined flags and context constraints (role, environment, date, IP, expression language), evaluated in-process with no external calls. It removes hand-rolled targeting code and integrates with DI/config/Twig. Caveats: it is Symfony-specific, has negligible community traction, and needs a pinned fork, dependency review, and an owner for upgrades and flag-cleanup discipline. If we standardize on Laravel, this is the wrong primitive — say so now.