Product Decisions This Supports
- Build vs. buy on recurrence entry UI. Recurrence pickers are a deceptively expensive UI: pattern selection, interval/ordinal controls, end conditions, human-readable summaries, and edit semantics ("this occurrence" vs. "this and following"). In a Filament admin panel this is commonly 2–4 sprints of work plus ongoing QA. Adopting a plugin turns that into a days-long integration, which is the core of the buy case here.
- Feature scoping for recurring anything. If the roadmap contains recurring appointments, event series, maintenance windows, retainer invoices, subscription renewals, shift patterns, or scheduled reports, this package gives a ready-made rule editor and a storage shape to design around — which forces the team to answer the hard product questions early: what rule vocabulary do users actually need, what happens on edit/delete of one occurrence, and how are exceptions represented.
- Roadmap sequencing. It unblocks a "recurring schedules" epic without pulling a frontend engineer off a higher-priority bet. Useful when the recurring feature is table-stakes plumbing rather than a differentiator.
- Internal-tools leverage. The best fit is admin/ops-managed schedules — a support or operations user configuring a series — rather than a consumer-facing calendar experience. That scope is where a Filament plugin's value is highest and its limitations are least visible.
- Dependency and risk budgeting. With ~21 stars and a single-maintainer profile, adoption is a conscious decision to accept vendor risk in exchange for speed. That is a legitimate trade only if the integration is wrapped behind an interface so it can be swapped without touching domain code. Treat that wrapper as a non-negotiable line item, not an engineering nicety.
- Data-model decision. Adopting it implicitly favors storing a rule (RRULE-style) and expanding occurrences at read time, versus materializing child rows per occurrence. That choice drives reporting, query complexity, and edit semantics for the whole feature — worth an explicit ADR rather than letting the plugin decide it by default.
When to Consider This Package
Adopt when all of these hold:
- The product surface is a Filament admin panel (confirm the supported Filament major version and pin it — Filament majors move fast, and a plugin lagging one major behind becomes a panel-upgrade blocker).
- Recurrence is configured by internal staff, not end users with demanding expectations around drag-to-reschedule, multi-timezone display, or per-occurrence overrides.
- The team is PHP/Laravel-native with limited frontend capacity, so a server-rendered form component is genuinely cheaper than a bespoke JS picker.
- The blast radius of abandonment is contained: a handful of admin screens, not the core booking engine or billing ledger.
- MIT licensing is compatible with your distribution model and there is no procurement requirement for vendor support.
Look elsewhere when any of these hold:
- You need the scheduling engine, not just the editor. Occurrence expansion, DST-correct timezone handling, exception/override semantics, and RRULE edge cases (
BYSETPOS, BYYEARDAY, floating times) are where these features actually break. Pair the UI with a proven library (e.g. rlanvin/php-rrule, sabre/vobject) and own that logic explicitly — or verify in a spike exactly what the plugin guarantees. Do not assume the editor implies a correct engine.
- Your frontend isn't Filament. Livewire-adjacent is fine; Inertia/React/Vue or a public-facing SPA gets little value here.
- The feature is customer-facing and core to the value proposition. Differentiating scheduling UX should not sit on a 21-star dependency.
- You need a supported vendor, security review artifacts, or an SLA — for example, recurrence touching billing or regulated scheduling.
- Compliance or multi-tenant isolation requires auditable, first-party code in this path.
Minimum due diligence before commit: a 1–2 day spike covering Filament version compatibility, upgrade path, DST behavior across a spring-forward boundary, behavior when a rule is edited after occurrences exist, and a read of the maintenance history and open issues.
How to Pitch It (Stakeholders)
For executives: We need recurring scheduling in the admin panel. Building the recurrence editor ourselves costs roughly 2–4 sprints plus permanent maintenance; this package is MIT-licensed and lets us ship the same capability in one short integration. The risk is concentrated and manageable: it's a small, single-maintainer project, so we isolate it behind an internal interface and spend two days validating it before committing. Worst case we remove it without touching our domain logic. Recommendation: approve a two-day spike, then decide — not a permanent commitment.
For engineering: Treat this as a UI component, not a scheduling engine. Pin the Filament version, wrap it behind a RecurrenceRule value object so no package model leaks into the domain layer, and write our own tests for DST transitions, rule edits after occurrences exist, and exception handling. Confirm whether occurrence expansion is in scope for the package or ours to own — plan for the latter. If the spike shows friction on our Filament version or unclear maintenance cadence, we fall back to php-rrule plus a bespoke form and keep the wrapper either way.