Client Laravel Package

Product Decisions This Supports

• Decouple deploy from release. The single biggest PM-level payoff: engineering can merge and ship code continuously to production behind a flag, while you decide when a capability becomes visible to customers. This is what makes a weekly or daily release cadence compatible with launch calendars, comms plans, and support readiness.
• Progressive delivery and blast-radius control. Roll a feature out at 1% → 5% → 25% → 100% by percentage, or target by user attributes (plan tier, tenant ID, region, signup cohort, internal staff). As of v2.11.084 the SDK also evaluates semver gte/lte constraints, so you can scope a change to "clients on app version ≥ 3.4.0" or "API consumers below v2" — useful when the server-side rollout has to track what actually shipped to mobile or to partner integrations. This converts a launch from a binary bet into a sequence of reversible decisions.
• Kill switches. Wrap a new checkout flow, a third-party integration, or an expensive query path so that an on-call engineer can disable it in seconds without a rollback or hotfix. Directly reduces MTTR and incident severity; worth scoping because it changes your incident-response runbook.
• Beta / early-access programs and dogfooding. Target named accounts or an allowlist without maintaining a bespoke if ($user->is_beta_tester) table that quietly becomes load-bearing production logic.
• Version-gated deprecations and migrations. The same semver operators let you turn things off on a schedule — sunsets, legacy endpoint retirement, forced-upgrade prompts — per client version rather than per deploy. This is the unglamorous half of lifecycle management and it is where teams usually end up writing bespoke comparison logic.
• Experimentation — with a caveat. Flags give you clean assignment and variants (A/B/C) with sticky bucketing, but Unleash is not a statistics engine. If experimentation is a real roadmap pillar, plan the analytics/warehouse side separately; do not let "we have flags" substitute for an experiment platform decision.
• Monetization / entitlement gating — use with care. Flags are fine for soft gating and packaging experiments, but should not be the authoritative source of truth for what a paying customer has purchased. Billing entitlements belong in your billing system; flags can gate UI exposure of those entitlements. Make this boundary explicit before a pricing change ships.
• Build vs. buy: the decision here is buy the evaluation layer, build the wrapper. You are buying a maintained, multi-language flag client and (optionally) an admin UI, audit log, and approval workflow that you would otherwise grow badly in-house. You are still building the Laravel integration, the flag-naming convention, the ownership model, and the flag-removal process.
• Roadmap hygiene. Every flag is a temporary branch in your product's logic and a permanent entry in your support matrix. Budget for a flag lifecycle (created → rolled out → cleaned up) as a tracked metric, not an afterthought.

When to Consider This Package

Adopt when:

• You run PHP/Laravel in production and want flags without adopting a proprietary, per-seat-priced SaaS. The SDK is MIT-licensed, official to the Unleash project, and framework-agnostic, so it works in a Laravel monolith and in adjacent PHP services using the same flag definitions.
• You need self-hosting or data residency — Unleash can run in your own infrastructure, which matters for regulated customers, on-prem deployments, or procurement teams that block third-party SDKs phoning home.
• You have more than a handful of flags, multiple environments, or more than one team writing them. At that point ad-hoc config('features.*') booleans lose auditability: nobody knows who enabled what, when, or why.
• You need consistent evaluation across services — same targeting rules in the Laravel app and in a queue worker or PHP microservice, including constraint logic. The v2.11.084 semver support narrows one of the remaining parity gaps with the JS/Go clients, which matters if you run version-targeted strategies.
• You want vendor optionality. Because the SDK is thin and the server is open source, the migration cost away from Unleash is materially lower than from a closed platform. That is a defensible risk position to take to an exec.

Look elsewhere or defer when:

• You have one team and a few booleans. Laravel Pennant is first-party, zero-infrastructure, and already in the framework. Adding an Unleash server, an SDK, and a polling client to toggle three screens is over-engineering. Revisit when flag count, environment count, or audit requirements cross a threshold.
• You need rigorous experimentation. Unleash's experimentation is not its center of gravity. If A/B testing with sequential testing, CUPED, and warehouse-native analysis is core, evaluate LaunchDarkly, Statsig, Eppo, or GrowthBook instead of bending flags into that role.
• You have no appetite to operate a service or pay for a managed tier. Someone must own the Unleash server (or the Unleash Pro/Enterprise subscription), its availability, backups, and upgrades. A flag service that is down is a deploy-blocking dependency; decide up front whether the SDK's local cache/backup-file fallback satisfies your availability story.
• Ecosystem maturity is a hard gate. This package has a modest footprint (roughly 65 stars, no dependents recorded). It is maintained under the official Unleash organisation and is one of many language SDKs, so bus factor is better than the raw numbers imply — but the PHP client is not where the community gravity is. If your organisation mandates vendor support SLAs and reference customers, validate that before committing.
• You require deep Laravel ergonomics out of the box — Blade directives, middleware, queue-aware context. The SDK is a plain PHP client; you will write a service provider, a facade, and a context resolver yourself. That is a day or two of work, not a blocker, but it is your code to own.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are proposing to standardise feature releases on Unleash, an open-source feature-flag platform, via its official PHP SDK. The business case is risk and speed, not features: it lets us ship code to production continuously while controlling exposure to customers, roll a change back in seconds during an incident instead of an emergency redeploy, and run paid-tier, regional, or app-version rollouts without one-off code. Because the server is open source and MIT-licensed, we avoid per-seat SaaS pricing that scales badly as we add engineers, and we retain the option to self-host for data-residency or on-prem commitments. The commercial exposure is close to zero — no licence fee, no lock-in — and the primary cost is a short integration effort plus a flag-governance process we should adopt anyway.

For engineering: This is a thin, framework-agnostic client — a service-provider wrapper, a context resolver (user ID, tenant, plan, region, and app/API version), and a caching/backup-file fallback is roughly the whole integration. It supports gradual rollout, strategy-based targeting, variants, and — new in v2.11.084 — semver gte/lte constraint evaluation, so version-range strategies behave the same here as in the JS/Go clients instead of forcing a server-side workaround. It polls for changes with local caching so evaluation stays in-process and fast. No vendor lock: the server is open source and the SDK is MIT, so the exit cost is low. The work to plan for is governance, not code — naming conventions, ownership per flag, environment promotion, and a cleanup backlog — plus confirming that a flag service outage degrades to cached state rather than taking deploys down with it. Treat the SDK as a pinned, deliberately upgraded dependency; this release was additive and non-breaking, but the changelog volume between minor versions is steady enough that silent auto-upgrades are not worth the risk.

Risks to acknowledge, briefly: the PHP client has a small community footprint relative to the JS/Go SDKs, so treat upgrades as a deliberate dependency rather than an ambient one; the SDK gives us flags, not experimentation analysis; and without a flag-retirement practice we will accumulate dead branches and a confusing support matrix within two or three quarters. Recommend gating adoption on a named owner and a tracked stale-flag metric.

Suggested success measures: release frequency and lead time for changes; percentage of launches using progressive rollout; incident MTTR for flag-guarded components; count of stale flags older than one release cycle; and zero rollbacks attributable to a flag misconfiguration.