Filament Visual Cron Builder Laravel Package

Product Decisions This Supports

• Admin/ops UX for scheduled jobs: Replacing a raw cron TextInput with a visual builder directly affects whether non-technical operators (ops, support, account managers) can safely create and edit schedules. This is a usability decision, not just a UI polish one — it changes who can self-serve schedule changes without engineering tickets.
• Build vs. buy: A five-column Every/Specific/Range/Step builder plus parsing, human-readable output, and a validation rule is roughly 2–5 days of engineering plus ongoing edge-case maintenance (DST, */n semantics, month/day-of-week OR behavior). Adopting this package is a credible "buy" for anything short of a core scheduling product.
• Roadmap scoping: The package's scope is deliberately narrow — a form field and a cron expression utility. That means it does not decide your scheduling architecture. You still own the queue/runner layer, job dispatch, timezone policy, and audit trail. Treat it as a UI + parsing dependency, not a scheduling platform.
• Feature bets it unlocks cheaply: exposing schedule configuration to tenants (multi-tenant admin panels), letting customers define report/digest cadence, and surfacing "next run" previews to reduce misconfiguration support load. The next-run preview is arguably the highest-value line item here — most cron bugs are "I didn't realize that meant every 5 minutes."
• Risk posture: v1.0.0 with no prior assessment and no usage data means you are an early adopter. That's a legitimate decision for an internal admin convenience feature; it's a weaker decision if the cron field sits on a customer-facing surface where a rendering bug blocks revenue operations.

When to Consider This Package

Consider adoption when most of the following hold:

• You are on Filament v4 (the field targets v4 specifically — this is a hard constraint, and the single biggest adoption gate).
• You already store cron strings in a column and render them with a plain TextInput. This package is a near drop-in swap, which keeps migration cost low and makes a trial cheap to reverse.
• The people editing schedules are non-engineers, or engineers who edit infrequently enough that cron syntax is error-prone.
• You are comfortable being an early adopter on a 1.0.0 with a small surface area — the blast radius of a bug is a misconfigured schedule in an admin form, which is recoverable.
• You want the parsing/validation logic (CronExpressionBuilder, ValidCronExpression) as a reusable server-side primitive, not just a widget — useful for API validation and importing existing schedules.

Look elsewhere or build in-house when:

• You are on Filament v3 or not on Filament at all. The cron-composition logic is not obviously separable from the field; if you need headless cron parsing, a mature standalone cron library is the safer dependency.
• You need timezone-aware scheduling semantics, DST handling, or "run at 9am in each user's local time." Standard 5-field cron does not express this, and nothing in the notes suggests the package addresses it. Do not let a nice UI imply a scheduling guarantee you don't have.
• You need 6-field cron with seconds, or calendar-style schedules ("first business day of the month," "last weekday"). Cron cannot express these; a visual builder would either mislead users or refuse inputs.
• Your scheduling config is customer-facing and revenue-critical, and you need vendor support, a security review, or an SLA. A fresh 1.0.0 from a single maintainer typically fails procurement.
• You require audit trails on schedule changes. The field gives you a form input, not change history — budget for that separately.

How to Pitch It (Stakeholders)

For executives — one paragraph: This package replaces a raw cron text box in our admin panel with a visual scheduler that shows a plain-English preview and the next run time. The business case is reduced dependency on engineering for routine schedule changes and fewer misconfiguration incidents, which are a recurring source of silent data/reporting failures. Cost to adopt is low and reversible: it is a form-field swap on an existing column, not an architecture change. Main caveat is maturity — it is a brand-new 1.0.0 release — so the recommendation is to pilot it on an internal, non-customer-facing screen first and revisit once we have usage evidence.

For engineering — the honest summary: It's a Filament v4 field plus a small cron parsing/validation utility. It solves a real problem we'd otherwise hand-roll, and ValidCronExpression is useful beyond the form for API and import validation. Constraints to confirm before committing: Filament v4 only, standard 5-field cron semantics only, no timezone or DST awareness, no seconds field. We should verify the human-readable output and next-run calculation against our own timezone handling rather than assume they agree, and we should keep our own validation at the persistence layer so the package is a UX convenience rather than a correctness dependency.

Recommendation: Adopt as a piloted dependency on internal admin surfaces; do not yet treat it as load-bearing for customer-facing or revenue-critical scheduling. Revisit the assessment once we have adoption data, a Filament v3 story, or evidence of maintainer responsiveness to issues.