Product Decisions This Supports
- Scheduling time-boxed releases without a release train. A time-window flag is active only between two timestamps, letting product schedule a launch, promotion, seasonal surface, beta, or contractual entitlement window at config time instead of coordinating a deploy or filing a "remember to flip it" ticket.
- Expiry-by-default flag hygiene. Most flag debt comes from flags nobody removes. Encoding the removal date inside the flag definition supports a standing product policy that every temporary flag carries a mandatory sunset — which is a roadmap-level decision about how we manage releases, not just a technical one.
- Build-vs-buy for a deliberately small primitive. The underlying logic is a date comparison plus a flag check. The real PM question is not "adopt this package" but "do we want a shared, tested, timezone-explicit
TimeWindow primitive wired into Laravel Pennant or a Gate, or do we accept ad-hoc if (now()->between(...)) comparisons scattered across the codebase?"
- Concrete use cases worth scoping into the backlog: scheduled campaign launches with hard end dates; trial and entitlement windows; maintenance or downtime banners; holiday pricing or content; time-limited A/B tests; conference and event microsites.
- A framework reality check that changes the decision. Despite being surfaced as a Laravel/PHP package, this is a Symfony bundle with 0 stars and 0 dependents. In a Laravel codebase it will install but never boot — there is no bundle registration or container extension loading in Laravel. The product-relevant value is the pattern (a composable, timezone-aware window object), not the artifact. It should inform an internal primitive, not a Composer entry.
When to Consider This Package
Consider it — or, more accurately, consider borrowing its design — when:
- You are on Symfony and already have a feature-flag abstraction its interfaces can plug into.
- You have a small, bounded set of time-windowed flags — a handful, not hundreds — where config-file definitions are sufficient.
- You are comfortable vendoring or forking, because maintenance signals are effectively zero: no adoption, no dependents, no visible release cadence. Treat it as an unmaintained reference implementation, not a dependency of record.
- You want a cheap spike — one to two days — to confirm the pattern fits before building it in-house.
Look elsewhere (or rather, build in-house) when:
- You are on Laravel. Use Laravel Pennant, a Gate/scope, or a scheduled command. The framework mismatch alone disqualifies it as a direct dependency.
- You need targeting beyond time: percentage rollouts, user or segment targeting, experimentation, or holdouts. Reach for Pennant, Unleash, LaunchDarkly, Flagsmith, or GrowthBook.
- You need governance: an admin UI, audit trail, per-environment promotion, approval workflow, or vendor SLA.
- You have timezone-sensitive or calendar-complex windows — recurring business hours, DST boundaries, midnight-crossing ranges. A naive start/end pair will not carry that, and neither will a ~50-line bundle with no evidence those cases were considered.
- Supply-chain or long-term ownership risk matters more than a few days of build effort.
How to Pitch It (Stakeholders)
To executives: This is a small, low-cost capability with a clear product payoff — it lets us schedule time-limited features without extra deploys or manual switch-flipping, and it forces every temporary flag to carry its own expiry date, which directly reduces flag debt and dead code paths. It is MIT-licensed and trivial in scope, so the financial risk of evaluating it is near zero. The caveat is equally simple: the project has zero adoption and no visible maintenance, and it targets Symfony, not our Laravel stack. Recommendation: fund a short spike, not an adoption. The likely best outcome is a small internal primitive modeled on this pattern — roughly a day or two of engineering — with no external dependency.
To engineering: We are not proposing a dependency on a zero-star Symfony bundle in a Laravel app; it would install cleanly but never boot. We are proposing to steal the design: a TimeWindow value object (start, end, explicit timezone) composed with Pennant or a Gate, declared in config/feature-flags.php, with unit tests covering DST transitions, midnight-crossing windows, and timezone offsets. Pair every window with a manual override so ops can force-enable or force-disable during an incident — a purely clock-driven flag has no kill switch. That gives us the same product capability with no framework mismatch, no supply-chain exposure, and full ownership, and we can validate the idea against this repo in a day.
Decision criteria to bring back: time-to-launch for scheduled features, the number of stale flags currently live in production, and the cost of owning a vendored micro-dependency versus an internal primitive.