Featuretoggle Bundle Laravel Package

Product Decisions This Supports

• Feature Flagging Strategy: Enables gradual rollouts, A/B testing, and canary releases for new features without deploying code changes. Aligns with iterative development and risk mitigation.
• Build vs. Buy: Avoids reinventing feature toggle infrastructure, reducing dev effort while maintaining flexibility. Ideal for teams prioritizing speed over customization.
• Roadmap Flexibility: Supports dynamic feature enablement/disablement via config (e.g., features.yml), allowing product teams to pivot without code changes.
• Use Cases:
  • Dark launching experimental features (e.g., new checkout flow).
  • Enabling/disabling features per environment (dev/staging/prod).
  • Segmented rollouts (e.g., by user role, region, or percentage).
  • Compliance/testing (e.g., toggling GDPR-related features).

When to Consider This Package

• Adopt if:

  • Your team uses Symfony 5.4+ and PHP 8.0+ (compatibility is non-negotiable).
  • You need lightweight, config-driven feature toggles (no complex backend required).
  • Your toggles are static or semi-dynamic (not real-time user-specific; consider a dedicated service like LaunchDarkly if dynamic targeting is critical).
  • You’re early-stage or lack dedicated backend resources for custom toggle infrastructure.
  • Your toggles are Symfony-centric (e.g., Twig integration for frontend toggles).

• Look elsewhere if:

  • You need real-time, user-specific toggles (e.g., per-user experiments) → Use a SaaS like Flagsmith or LaunchDarkly.
  • Your stack is non-Symfony (e.g., Laravel, Node.js) → Evaluate alternatives like spatie/laravel-featureflags.
  • You require audit logs, analytics, or admin UIs for toggles → Consider a dedicated feature flag service.
  • Your team needs multi-tenant toggle management → Custom solution or enterprise-grade tools may fit better.
  • The package’s maturity/activity is a concern (last release in 2022; low stars/dependents).

How to Pitch It (Stakeholders)

For Executives: "This package lets us control feature visibility with a simple config file—no backend work required. We can safely roll out new features to subsets of users, test hypotheses, or disable broken functionality instantly. It’s a low-risk way to accelerate iteration without over-engineering. For example, we could toggle a new subscription flow for 10% of users in staging before full launch."

For Engineering: *"It’s a lightweight Symfony bundle that adds feature toggles via YAML config (ignored by Git). Key benefits:

• Zero backend code: Toggle features by editing features.yml (e.g., new_checkout: true).
• Twig support: Toggle UI elements directly in templates (e.g., {% if feature('new_ui') %}...{% endif %}).
• Symfony-native: Integrates seamlessly with existing services/containers.
• Simple setup: Composer install + config file in 10 minutes. Tradeoff: Not real-time (config reloads needed), but perfect for most use cases. If we hit limits, we can migrate to a SaaS later."*

For Product: *"This gives us the power to:

• Test features quietly (e.g., hide a new CTA from most users).
• Kill switches for critical bugs (disable a feature instantly).
• Segmented releases (e.g., enable for paying users only). No dev dependency—just a config file. We can start using it today without blocking the roadmap."*