Laravel Scheduled Action Laravel Package

Product Decisions This Supports

• Feature scoping for time-based state changes. The package addresses a recurring product pattern: "this record should change state at a future time" — scheduled publishing, trial/entitlement expiry, archival, grace-period soft deletes, deferred notifications. That's a reusable primitive across several roadmap items, not a one-off.
• Build vs. buy (adopt) evaluation. MIT-licensed, narrow surface area, no vendor lock-in. The realistic decision is "adopt as-is," "vendor the pattern in-house," or "ignore" — not a procurement exercise.
• Roadmap sequencing. If scheduled state transitions are a foundation for 2–3 near-term features, adopting a thin convention early avoids each team hand-rolling its own timestamp column + scheduled command. If only one feature needs it, a bespoke 50-line solution is cheaper than any dependency.
• Use cases it plausibly covers: content publish/unpublish windows, subscription downgrade at period end, account deactivation after inactivity, staged rollouts per-tenant, delayed reminders.
• What it explicitly does not decide for you: it is not a workflow engine. No multi-step approvals, branching, compensating actions, or cross-service orchestration. If the product requirement is "approval chain" or "retry with backoff and dead-letter," this package is the wrong abstraction.

When to Consider This Package

Consider it when:

• You're on Laravel and already modeling domain state in Eloquent.
• The requirement is genuinely a per-model timestamp-driven transition, not a general job scheduler.
• You're comfortable owning the code — i.e., you'd fork or vendor it, not depend on upstream.

Look elsewhere when:

• You need durable, multi-step workflows (Temporal, Laravel Workflow, or a queue-based state machine).
• You need cron/recurrence semantics — Laravel's own scheduler already covers that.
• The work must survive infrastructure changes or span services.

Risk assessment (material to the decision):

• 18 stars, 0 dependents, last release March 2023. That is effectively zero community validation and a strong signal of upstream abandonment. Assume no Laravel 11/12 compatibility guarantee until verified.
• Audit before adoption: Laravel version constraints, timezone/DST correctness on stored timestamps, idempotency (does re-running double-fire an action?), and concurrency safety under multiple queue workers (withoutOverlapping, atomic claims).
• Verdict: treat as a reference implementation, not a dependency. A 1–2 day spike to read the source and extract the pattern is the high-value move; installing it as a critical-path dependency is not.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed building block that could let us ship "schedule it for later" features — publishing windows, trial expiry, staged rollouts — faster and consistently. Cost of evaluation is a couple of engineer-days; risk is low because we can absorb the code if the project is abandoned. Recommendation: pilot on one non-critical feature, do not standardize.

To engineering: Thin API, small codebase, no lock-in — but unmaintained since early 2023 with no dependents. Propose a timeboxed spike to (a) verify Laravel version compatibility, (b) validate idempotency and multi-worker safety, and (c) decide between adopting, vendoring the pattern, or writing our own. Do not add as a critical dependency without that audit.

Decision requested: Approve a 1–2 day spike; default outcome is an internal implementation inspired by the package rather than a dependency on it.