Featurit Sdk Symfony Laravel Package

Product Decisions This Supports

• Feature flagging as a delivery capability, not a one-off hack. This SDK gives Symfony services a first-class client for a hosted feature management platform, so PMs can decouple deploy from release: dark-launch a feature, ramp it to 1% → 10% → 50% → 100% of users, and kill it instantly without a rollback deploy. That directly shortens the feedback loop between "code shipped" and "users seeing it." As of v0.8.0 the flag cache can be backed by our own Symfony cache pool, which makes it practical to put flags on more surfaces than a pilot route.
• Roadmap sequencing and de-risking bets. Because flags are evaluated per-user/per-segment at runtime, you can ship multiple roadmap items behind independent flags in the same release train and decide when each becomes visible. This lets us commit to fewer, larger releases while keeping the option to pull a bet forward or abandon it cheaply.
• Progressive rollout and entitlement gating for paid tiers. Useful for pricing/packaging decisions — gate a capability behind a plan-level or account-level flag rather than hard-coding tier checks, so sales-led exceptions and beta cohorts don't require engineering tickets.
• Experimentation groundwork. Flag targeting segments are the prerequisite for A/B tests and holdout groups. Adopting this now positions the team to answer "did this feature move the metric?" later, without a second integration.
• Operational risk moved from "vendor's problem" to "our config." The v0.8.0 cache-injection change is the single most commercially relevant update so far: we can now point flag caching at an existing Redis/cache.app pool instead of accepting the vendor's default polling behavior. That converts "external HTTP dependency in the request path" from an open risk into a tunable one — the flag evaluation can be served from cache we already operate, monitor, and have an SLO for.
• Build vs. buy signal. The existence of a thin vendor SDK shifts the question from "do we build an internal flag service?" to "do we buy a flag service and pay the integration tax?" The integration tax just got smaller (custom cache is one less thing to hand-roll), while building internal flag infrastructure with audit logs, targeting rules, and an admin UI remains a multi-quarter effort.
• Vendor evaluation, not a commitment. For a PM, this package is a low-cost way to run a two-sprint spike against FeaturIT's actual evaluation semantics before signing anything. With v0.8.0 that spike can now include a realistic latency test against our production cache topology rather than a synthetic one.

Important framing caveat: despite the brief describing this as a "Laravel/PHP package," this is a Symfony bundle. If your stack is Laravel, this is not drop-in — you would either wrap the vendor's core PHP SDK in a Laravel service provider/facade yourself, or evaluate Laravel Pennant (first-party, free) or a Laravel-native SDK from a competitor. The v0.8.0 cache work does not change this; it is still Symfony DI/config wiring, so it removes none of the Laravel integration cost. That distinction alone may invalidate the adoption case.

When to Consider This Package

Consider it when:

• Your application is Symfony 6.x/7.x and already uses the Symfony service container and autowiring — the bundle's value is config-driven service registration and DI wiring, which is exactly what you'd otherwise hand-roll.
• You have already selected FeaturIT (or are in a paid pilot) as your feature management vendor. The SDK is a client, not a platform — it has no value without a FeaturIT account and API key. Adopting the SDK is a consequence of the vendor decision, never the driver of it.
• You need server-side flag evaluation in PHP with user-context targeting, and you want the vendor to own polling while you own the cache. Since v0.8.0 you can inject a custom cache implementation from the Symfony project (backed by the underlying PHP SDK 1.0.0), which is the right shape for teams that already run Redis/APCu and want flag reads off the network.
• Your flags are operational and product-facing, not high-volume per-request hot-path decisions where an external HTTP dependency is unacceptable. The cache-injection change materially improves this, but it is not a blank cheque — you still need to confirm the SDK degrades gracefully on cache miss and on a cold cache after deploy, and that the injected cache honours your TTL/staleness policy.
• You have tolerance for a young, single-vendor integration: 4 GitHub stars, 0 dependents, first release January 2025, bundle still on 0.x despite the underlying SDK now being 1.0.0. That's a pre-community library. Adopt only if the vendor's commercial support contract is your safety net, not the OSS community.

Look elsewhere when:

• You're on Laravel. Use Laravel Pennant (free, first-party, database or array driver) for simple flags; go to LaunchDarkly, Unleash, Flagsmith, or GrowthBook if you need targeting UI, experiments, or audit trails. Any of these is a more defensible choice than hand-porting a Symfony bundle — and v0.8.0's cache feature is not a substitute for a Laravel-native integration.
• You want self-hosted or open source. Unleash and Flagsmith have OSS servers; FeaturIT is a commercial SaaS. If data residency, procurement friction, or per-seat cost is a concern, exit here. (Note the new cache injection improves latency, not residency — flag definitions still come from the vendor.)
• You need a mature ecosystem. With 4 stars and 0 dependents there is essentially no community debugging surface — every issue is a vendor ticket. For a flag system that gates production behavior, that's a real operational risk to weigh. A 0.8.0 → next bump could also churn the cache/config surface again.
• Your flag needs are trivial. If you need three boolean toggles for two engineers, environment variables or a config file are cheaper than a vendor contract, an SDK, and a new external dependency in your request path.
• You need client-side/mobile flag evaluation — this is a server-side SDK; check that FeaturIT's other SDKs cover your front-end surfaces before standardizing.

On the v0.8.0 upgrade specifically: no deprecations or breaking changes are announced for the bundle's public surface, but it pulls in a major SDK bump (PHP SDK 1.0.0) — the point where a vendor typically stops making breaking changes, not a guarantee it hasn't just made one. Treat the version bump as a task: pin the bundle, re-run the spike's latency and failover tests against a real injected cache, and diff evaluation semantics before rolling to more than one surface.

How to Pitch It (Stakeholders)

One-line summary: A thin Symfony integration for the FeaturIT feature-flag service that lets us ship code continuously while controlling who sees what, when — and, as of v0.8.0, run flag evaluation off a cache we already own — recommended for a scoped two-sprint evaluation, not an immediate production commitment.

For executives: This is a buy-side integration for a capability we will need regardless of vendor — the ability to turn features on and off per customer segment without redeploying. The integration cost is small (days, not weeks), but the underlying commitment is a SaaS subscription plus a new runtime dependency in our application. The newest release meaningfully de-risks the technical side: we can now plug our own cache into flag evaluation instead of accepting the vendor's default, so flag lookups need not hit the network on every request and we inherit the monitoring and uptime we already have. The recommendation is unchanged: pilot on one non-critical surface, measure operational overhead, and decide on a commercial agreement after. Two things still carry risk — the library remains a single-release, near-zero-adoption open-source project (the 1.0.0 is the vendor's SDK, not evidence of a community), and the commercial terms, not the code, are what we would actually be relying on.

For engineering: This bundle wires FeaturIT's PHP SDK into Symfony's DI container and config, saving us roughly a day of boilerplate for client instantiation, API key config, and cache setup. v0.8.0 upgrades the underlying SDK to 1.0.0 and lets us inject a custom cache implementation from the Symfony app — which means we can bind flag caching to our existing Redis/cache.app pool and get flag reads off the request-path network hop. The trade-offs are unchanged in kind but now more tractable: (1) it's Symfony-only — a Laravel equivalent would be our own wrapper around the core PHP SDK, and this release does not help there; (2) the external dependency still exists on cache miss/cold start, so validate the injected-cache path against our latency and availability targets, including behaviour when the vendor API is unreachable; (3) it is a single-maintainer, pre-1.0-community bundle whose dependency just had a major version bump, so pin both versions and be prepared to fork or wrap if the vendor's release cadence stalls. Suggest a spike that wraps flag access behind our own interface so the vendor — and the cache implementation — can be swapped without touching call sites.

Decision requested: Approve a timeboxed evaluation with a vendor-owned flag interface abstraction, now including a test of the custom cache injection against our real cache topology, and defer the commercial decision until we have latency numbers and a support-terms review.