Toggle Laravel Package

Product Decisions This Supports

• Staged rollout and progressive delivery. This package enables the core PM move: ship the code now, expose it to users later. Feature work can merge behind a flag rather than waiting for a "release day," which shortens the time between a decision and a customer seeing it.
• Trunk-based development and release/feature decoupling. Engineering can integrate continuously while product controls exposure. This is often the real driver of adoption — the value is as much in reduced merge risk and fewer hotfix windows as in the flag itself.
• Kill switches for risky surface area. New checkout flow, new pricing display, third-party integration — flag it so a rollback is a config change rather than a revert-and-redeploy under pressure. Note the constraint below: because this package is config-file based with no database, "flip the flag" means "deploy." That's fine for planned rollbacks, not for a live incident command.
• Entitlement and packaging decisions. Gate beta access, paid-tier-only features, or regional availability. This lets you sell or announce a feature before it's universally available, and lets you reverse a packaging decision without a code change.
• Build vs. buy for flag infrastructure. This is the cheapest possible option: no SaaS subscription, no vendor data processing agreement, no PII leaving your infrastructure, no per-seat or per-MAU cost. The trade-off is you buy capability, not just cost — you get static, environment-scoped flags and nothing more.
• Experimentation — with a caveat. You can run coarse A/B tests (on for a cohort, off for another), but without per-user targeting, percentage ramp logic, or an assignment service, you should not treat this as an experimentation platform. Don't let a stakeholder hear "feature flags" and assume "we can run experiments and measure uplift."
• Roadmap sequencing input. Flags let you stage a launch as internal → design partners → 5% → 100%. That staging plan is a product decision worth writing down up front, and this package is enough to execute it.

The constraint that shapes all of the above: with no database and config-file-only definitions, every flag change is a deploy, and flag state is owned by engineers, not by PMs, support, or growth. Any decision that requires "flip it now, from the dashboard, for this one account" is out of scope.

When to Consider This Package

Reasonable fit when:

• The stack is Laravel-only and will stay that way.
• Flag count is small — tens, not hundreds — and flags are known at deploy time.
• Targeting is by environment (staging/production) or by a coarse code-level check, not by user ID, plan tier, geography, or cohort.
• You have no compliance requirement for flag-change audit trails, approvals, or segregation of duties.
• Nobody outside engineering needs to change a flag.
• You're willing to treat the underlying library as replaceable and wrap it.

Look elsewhere when:

• You need runtime flag changes without a deploy — incident response, support-driven overrides, growth experiments. That means a service (LaunchDarkly, Unleash, Flagsmith, GrowthBook) or at minimum a database-backed flag table you own.
• You need per-user, per-segment, or percentage targeting. This package's config-scoped model can't express "10% of free-tier users in EMEA."
• Maturity risk matters. Zero stars, a single maintainer, and a vendor prefix (sb-) that suggests a personal-namespace package. There is no community, no third-party security review, and no commercial support. Assume a bus factor of one and no guaranteed maintenance past the next Laravel major. For anything on a revenue-critical path, that's a real cost you should price in.
• Release discipline is a concern. The one notable change in this package's history is a config file rename shipped in a patch release (v1.0.1). Under semver, that's a breaking change published as a patch, and its failure mode is silent — stale config() calls return null and fall through to defaults instead of erroring. That tells you the project does not treat config keys as a stable public contract. Plan accordingly: pin the version, roll to staging first, read the changelog for every patch.
• You need flag lifecycle management. Nothing here enforces flag expiry, ownership, or cleanup. Flag debt is real and it becomes permanent technical debt — stale flags are dead code with extra steps, and each one is a branch in your product you can no longer reason about.
• Multi-language or multi-service. If flags need to be read by a Node service, a mobile client, or a data pipeline, a config-file-per-Laravel-app model fragments your source of truth fast.

The honest build-vs-buy read: for a small Laravel team with a handful of deploy-time flags, this is fine and free. The moment flags become a cross-functional tool — support overrides, growth experiments, per-tenant entitlements — the migration cost to a real flag service exceeds what you saved, and it's better to start on the right thing.

How to Pitch It (Stakeholders)

For executives: This is a small, free, open-source utility that lets us ship code and control when customers see it, without buying a feature-flag SaaS product. The direct value is reduced deployment risk and faster, more reversible launches — we can announce a feature, roll it back, or limit it to a beta group without an emergency engineering cycle. The cost is near zero in licensing; the cost we do carry is that flag changes require a deploy, and the library is young and maintained by one person. Recommendation: adopt behind a thin internal wrapper so it stays swappable, pin the version, and revisit if we need per-customer or self-service flag control.

For engineering: Framework-native, no database, no migrations, no new infrastructure. Define flags in a config file, read them in controllers, services, and Blade. Two asks before we merge it: (1) wrap it in a small app-level service provider with our own interface, so no controller ever calls the package directly and a future swap to LaunchDarkly or a DB-backed table touches one file; (2) treat config/sb-toggle.php as the contract — env indirection for environment-specific values, config:cache in the deploy pipeline, no env() calls scattered through application code. Also: v1.0.1 renamed the config file under a patch version, so pin to ^1.0.1, check config:show after every upgrade, and stage before production.

For the product org: Treat flags as temporary. Every flag gets an owner and a removal date when it's created, or it becomes permanent dead code. And be explicit about what this tool is not: it is not a dashboard, not self-service, and not an experimentation platform — if a launch plan needs "turn it on for this customer right now," that plan needs a different tool.