Laravel Model Statable Laravel Package

Product Decisions This Supports

• Lifecycle modeling as a first-class concern. This package lets Eloquent models carry states and lets those states be applied to models and their relationships. That directly supports decisions about how we model lifecycles (draft → published → archived, pending → paid → fulfilled, trial → active → churned) instead of scattering status columns and ad-hoc where('status', ...) clauses across the codebase.
• Build vs. buy for workflow plumbing. The recurring "should we hand-roll status enums, transition methods, query scopes, and relationship filtering, or adopt a package?" decision. A 1.0.0 release with model-level and relationship-level state application is enough to justify a time-boxed spike rather than a from-scratch build.
• Feature and roadmap sequencing. If states can be applied to relationships, we can plan features like "show only active line items on an order," "list published posts by author," or "filter tenants by provisioning state" without new join/filter logic per feature. That affects how we scope state-dependent roadmap items and estimate them.
• API and UI surface decisions. Once states are queryable on models and relationships, decisions about exposing state filters, state badges, and state-based permissions in admin/API layers become cheaper and more consistent.
• Standardization vs. per-domain solutions. Whether to adopt one lifecycle convention across domains (content, billing, onboarding) or allow domain-specific approaches. A single package lowers the coordination cost of standardizing.
• Risk posture for a new dependency. A first release informs the "pilot vs. bet" decision: use it in a low-risk domain first, and hold off on making it load-bearing for revenue-critical flows until the API and maintenance cadence are proven.

When to Consider This Package

Consider it when:

• The application is Laravel with Eloquent models that already have (or clearly need) a lifecycle with a small, well-understood set of states.
• You want states to be applied consistently to models and to relationship queries — e.g., filtering related records by state without bespoke scopes in every model.
• The team prefers a thin, convention-based layer over a full state-machine framework, and the states are mostly descriptive (status tracking) rather than heavily orchestrated.
• You are prototyping or building an internal/admin-facing workflow where a fast, low-ceremony implementation matters more than hardened guarantees.
• You want to reduce duplicated status-column logic across several models as a refactor or consistency play.

Look elsewhere or wait when:

• You need guarded transitions (allowed-from/allowed-to rules), side effects on transition, or event-driven workflows — the release notes describe applying states, not transition enforcement or transition hooks.
• You need an audit trail / state history for compliance or customer-facing timelines; nothing in the notes indicates history is captured.
• You need concurrency safety (optimistic locking, race conditions on state changes) or authorization integrated into transitions.
• The lifecycle is genuinely complex (many states, parallel substates, conditional transitions) — a dedicated state-machine library or Symfony Workflow-style solution is likely a better fit.
• You require a mature dependency with long-term support signals. At 1.0.0 with a minimal release note and no visibility here into docs, test coverage, or maintainer activity, treat it as early-stage.
• You are on a non-Eloquent data layer, or states must span non-model resources (jobs, external systems).

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small Laravel add-on that gives our database models an explicit "state" (like draft/published/active) and lets us filter related records by that state. The business value is less custom code and more consistency: lifecycle features — publishing flows, order status, onboarding steps — get built once, in a predictable pattern, instead of being reinvented per feature. Cost and risk are low to trial, but this is a brand-new 1.0.0 package, so the recommendation is to pilot it on a non-critical workflow, measure how much hand-written status logic it removes, and only then standardize on it. It is a productivity and consistency play, not a strategic platform bet.

For engineering (summary): The package applies states to Eloquent models and to relationships, which means state-aware querying on both the primary model and its related records. What the release notes do not cover — and what we must verify before broader adoption — is transition enforcement, state-change events, history/auditing, authorization hooks, and concurrency handling. Suggested approach: pin the version, wrap it behind our own small interface so we can swap it out, and validate behavior with tests on a single low-risk model before rolling it across domains.