State Laravel Package

Product Decisions This Supports

• Multi-step flow design (apply, checkout, onboarding, KYC): The package gives a durable "where is this user in the flow" pointer, which is the enabling primitive for resume-later, progressive disclosure, and back-navigation without re-fetching or re-validating everything.
• Build vs. buy for stateful wizards: This is the decision it most directly informs. The capability is commodity — a session/cache-backed state machine of a few hundred lines. The package's value is the pattern (pluggable cache vs. session store, expiring drafts), not the code volume. The v3.3.0 release is maintenance-only (version-floor changes: PHP 8.2+, Laravel 11+, psr/cache v3) and adds no capability — it does not move the build-vs-buy math in either direction.
• Draft persistence and abandonment recovery (roadmap candidate): Cache-backed state unlocks "email me my unfinished application" and cross-session resume, both of which are measurable funnel levers. Session-backed state does not — it dies with the browser.
• Anonymous vs. authenticated segmentation: The dual driver choice maps cleanly to a product rule: session for anonymous/low-stakes steps, cache with a user-scoped key plus TTL for logged-in users who may switch devices.
• Retention policy as a product decision, not an infra one: Whatever TTL you configure is your published draft-retention promise (e.g., "we keep your draft 30 days"). That belongs in the PRD, not in a config file owned by platform.
• Not supported: anything requiring durable audit history, financial-grade idempotency, or cross-service state sharing. Cache/session state is ephemeral by definition; do not let it drift into being the system of record.

When to Consider This Package

Adopt (as a dependency or, more likely, a fork/reference) when:

• You are on Laravel and need per-user flow state in days, not weeks, and the flow is genuinely throwaway (a wizard, a filter set, a staged upload sequence).
• You want the cache/session duality out of the box rather than hand-rolling a driver abstraction.
• Your team has no existing state-machine or workflow convention and would otherwise scatter session()->put() calls across controllers.
• You are already on Laravel 11+ and PHP 8.2+. As of v3.3.0 the package dropped illuminate/support and illuminate/session v10, PHP 8.1, and psr/cache v1/v2. If our apps are still on Laravel 10 or PHP 8.1, "adopting" means pinning a stale tag on an unsupported branch — which is a worse outcome than the in-house option below.

Look elsewhere — or write it yourself — when:

• License clarity matters. NOASSERTION means legal review is a prerequisite, not a formality. For a 17-star package with zero dependents and a single maintainer org, the cost of a license opinion likely exceeds the cost of reimplementation. This is the single biggest blocker, and v3.3.0 does not touch it.
• Zero dependents and 17 stars signal unproven production surface: no ecosystem pressure-testing, no community patches, no Stack Overflow corpus. Budget for reading the source, and expect to own it. The maintainer is demonstrably active (v3.3.0 adds PHP 8.5 support), which is a positive hygiene signal but not a substitute for ecosystem proof — and it means the package sets its own support window, not ours. A three-line release note just moved our framework upgrade calendar.
• You need durability or audit. Redis flush, eviction under memory pressure, or a cache namespace change silently destroys user state. If losing a draft is a support ticket or a compliance event, use a database-backed draft table with soft deletes.
• Multi-instance deployments without sticky sessions unless you configure the cache driver correctly and key by user, not by session ID.
• You need PII controls. State payloads frequently accumulate names, addresses, uploaded-document references. Verify what lands in the cache, whether it is encrypted at rest, and how it is purged on user deletion (GDPR erasure must reach the cache too).

How to Pitch It (Stakeholders)

For executives (one paragraph): We have a recurring pattern — users abandon multi-step flows (applications, onboarding, checkout) and cannot pick up where they left off, which costs us completed conversions. This package is a small, Laravel-native library that stores "where the user is" in cache or session so we can offer resume-later. It is not strategic technology and it is not a moat; it is roughly a few hundred lines of glue. The recommendation is therefore not to adopt it as a dependency, but to use it as a validated reference design and implement the pattern in-house in one sprint. That removes license ambiguity, supply-chain exposure (zero dependents, 17 stars, single maintainer), and the risk of a cache flush silently deleting user drafts. The newly published v3.3.0 is a maintenance release — framework and PHP version-floor changes, no new functionality — and does not change this recommendation. Expected upside is measured in funnel completion, not in engineering leverage — so we should fund it as a funnel experiment with a target metric, not as a platform investment.

For engineering (the ask): Spike the pattern, not the package. Concretely: (0) confirm our Laravel and PHP versions first — the current release requires Laravel 11+ and PHP 8.2+, so on Laravel 10 we would be pinning an unsupported tag, which is itself an argument for owning ~300 lines; (1) a FlowState contract with session and cache implementations; (2) cache keys namespaced flow:{type}:{user_id} with TTL sourced from a config value that Product owns; (3) a database fallback for flows where losing state is unacceptable; (4) explicit purge hooks on account deletion and flow completion. Track resume-rate, step-drop-off, and recovered-completion as the success metrics. If the license resolves cleanly and we later want a stopgap, this repo is a reasonable read for prior art — but treat it as a sketch, not a foundation.