Laravel Pennant Dashboard Laravel Package

Product Decisions This Supports

• Feature rollout and progressive delivery: Gives PMs and operators a dashboard for Laravel Pennant flags, supporting beta cohorts, percentage rollouts, canary releases, and GA decisions without engineering tickets for every toggle.
• Build vs. buy: A Pennant dashboard is commodity infrastructure. Using this package avoids building and maintaining an internal flag admin UI, while keeping flag evaluation inside the Laravel application.
• Release risk and incident response: Flag-based kill switches let teams disable risky features without redeploying. This supports roadmap commitments around safer releases and reduced blast radius.
• Experimentation and entitlement gating: Useful for gated features, plan-based access, internal dogfooding, and customer-specific enablement where a full experimentation platform is unnecessary.
• Upgrade and migration governance: v1.0.2 makes missing migrations visible through the dashboard, php artisan about, logs, and refused dashboard writes. This supports planning migration windows and prevents silent rollout stoppage after upgrades.

When to Consider This Package

Consider it when:

• Your application already uses Laravel Pennant and needs operational visibility or non-engineer-friendly flag controls.
• You can accept database migrations and a package-managed table set. Upgrading from 1.0.0 or 1.0.1 requires php artisan migrate; if run_migrations is false, migrations must be republished with php artisan vendor:publish --tag=pennant-dashboard-migrations.
• You want a lightweight, Laravel-native control plane for beta programs, internal rollouts, plan entitlements, or incident kill switches.
• You are on 1.0.0 or 1.0.1 and want the v1.0.2 safety behavior: missing migrations are surfaced loudly instead of flags silently falling back or dashboard writes returning 500s.
• You value fail-loud upgrade behavior and backward compatibility during migration: Rollout::decide() continues reading 1.0.0 tables as before until migration is complete.

Look elsewhere when:

• You are not on Laravel/Pennant, or you need multi-language SDKs, enterprise RBAC, approval workflows, audit trails, environment promotion, or vendor SLAs. In those cases, evaluate dedicated platforms such as LaunchDarkly or Unleash.
• You cannot add or manage database migrations, or you require zero-database flag evaluation.
• You need advanced experimentation statistics, warehouse-native analysis, or compliance-grade change management.
• The team cannot own package maintenance and upgrade discipline. This is a 1.x package; evaluate maintainer activity and fit against your support expectations.

How to Pitch It (Stakeholders)

For executives: This is a low-cost operational control layer for feature releases. It reduces release risk, shortens beta and experiment cycles, and gives product teams direct control over who sees what—without buying a large feature-flag platform or building an internal dashboard.

For engineering: It integrates with Laravel Pennant and adds a dashboard plus persistence. v1.0.2 is a patch release focused on upgrade safety: missing migrations now produce a dashboard banner, pending-migration visibility in php artisan about, one warning per process, and refused dashboard changes instead of silent rollout fallback or 500s. There is no new API break beyond the existing migration requirement; 1.0.0 table reads remain compatible until migration.

For product managers: It enables self-serve rollout decisions, beta management, and kill switches, reducing dependency on release trains. The trade-off is migration discipline: plan the php artisan migrate step, and if run_migrations is disabled, republish migrations before upgrading. Adopt v1.0.2 to make that step visible rather than silent.