Product Decisions This Supports
- Build vs. buy for recurrence logic. The package replaces a small but genuinely fiddly chunk of custom code — "given this model, when is the next occurrence, and create it" — that every recurring-invoice, recurring-task, subscription, rental, or maintenance-schedule feature reinvents badly. It shifts the decision from "do we staff a 3–4 week scheduling epic?" to "do we take a dependency and spend 2 days integrating?"
- Feature scoping. It makes the cheap version of recurring features viable now: one row per generated occurrence, driven by Laravel's scheduler. That's enough for reminders, task templates, planned maintenance, and invoice drafts. It is not a billing engine — proration, dunning, retries, tax, and SCA stay with your PSP (Stripe Billing, Chargebee, Lago). This distinction is the single most important product decision the package forces you to make explicitly.
- Data-model direction. Because occurrences materialize as real Eloquent rows (rather than being computed on read), reporting, editing a single occurrence, and audit trails come almost free — but you inherit volume growth and a "what happens when a rule is edited mid-stream?" answer you must own. Approving the package is approving that model.
- Roadmap sequencing. Unblocks recurring-value features ahead of any billing-platform migration. A reasonable path: ship recurrence with this package against invoice drafts, validate demand, then graduate to a PSP billing integration if collections become the bottleneck.
- Use cases that fit cleanly: recurring to-do/maintenance templates, scheduled content publishing, rent/utility reminders, subscription-style access renewals on non-monetary plans, recurring internal reports.
- Staffing and ownership. Small surface area means any Laravel developer can maintain the integration; it does not require a platform team.
When to Consider This Package
Adopt when:
- The app is Laravel-first and the recurring domain is genuinely Eloquent-shaped (models that "spawn themselves").
- You need simple, per-model recurrence with different rules per record — not a universal calendar engine.
- Your volume is comfortably handled by a single cron-driven scheduler, and "occurrence arrives within a few minutes" is an acceptable SLA.
- Your team is willing to own the operational edges: cron reliability, idempotency (unique constraint on
parent_id + occurrence_date), timezone/DST behavior, and catch-up after downtime.
- You're pre-product-market-fit or building an internal tool where a 1–2 day spike beats a multi-week build.
Look elsewhere when:
- Money movement is in scope at scale — use a billing platform and keep recurrence out of your app.
- You need real calendar semantics: RFC 5545 RRULE, "last Friday of month," holiday calendars, per-occurrence exceptions and reschedules. Combine
rlanvin/php-rrule with your own layer, or use a calendaring service.
- You need guaranteed-delivery scheduling, fan-out at high volume, or cross-language workers — use a cloud scheduler, Temporal, or a queue-native approach.
- You require vendor support contracts, SLAs, or a security review of every dependency. 266 stars and a single maintainer mean the support story is "you and the source."
- The team cannot absorb the maintenance burden if the maintainer goes quiet — mitigated only somewhat by MIT licensing (you can vendor and fork).
Vetting checklist before committing: Laravel/PHP version support matrix, test coverage and last-commit cadence, open-issue responsiveness, whether it guards against duplicate generation, and how it handles timezones and DST.
How to Pitch It (Stakeholders)
For executives: We need recurring behavior in [feature] and the alternatives are a 3–4 week internal build or moving to a paid billing platform. This MIT package covers the recurrence mechanics — deciding when the next record is due and creating it — in a few days of integration, at zero licensing cost and no vendor lock-in. It does not touch payments, so it doesn't change our compliance or finance posture. The exposure is a niche dependency (moderate adoption, one maintainer), but the scope is small and the license lets us take ownership of the code if needed. Ask: approve a two-day technical spike with a go/no-go on idempotency and timezone correctness.
For engineering: It's a trait you add to a model plus a scheduled command — convention over configuration, consistent with existing Eloquent patterns, so no new architectural concept to learn. Auditing it is an afternoon, not a quarter. The trade-offs you're accepting: occurrence rows are materialized (plan for growth and for rule-edit semantics), delivery depends on Laravel's scheduler staying healthy, and you must add your own uniqueness guarantee to make generation idempotent. Recommend pinning the version, adding a test around DST boundaries, and documenting the fallback plan (fork/vendor) in the ADR.
For finance and operations: Recurrence here means "the system creates the draft/reminder/record on schedule." It does not collect money, retry failed charges, or handle proration — that remains with our payment provider. Operationally, someone must monitor the scheduler and have a documented procedure for backfilling missed occurrences after an outage.