Laravel Business Process Laravel Package

Product Decisions This Supports

• A shared vocabulary for a recurring class of roadmap work. Approvals, KYC, onboarding, order lifecycle, subscription dunning, claims — the recurring shape is "multi-state, multi-actor, rules-based." This package is the candidate for expressing those processes as named, reviewable definitions in our Laravel codebase instead of each feature reinventing status columns and scattered if checks.
• A third option in build vs. buy. The real choice is not "hand-roll a state machine or buy a BPMN platform." It is: is process orchestration a differentiator for us? If not, reuse a small library. If yes, staff it deliberately. Hand-rolling a state machine well — guards, transition tables, auditability — is deceptively expensive, and this package is a legitimate answer to the cheap-but-correct tier.
• Scope discipline on workflow-adjacent requests. A defined process model lets product reframe "rewrite the order module" as "add a transition with a guard." That bounds cost, makes estimates credible, and gives engineering a shared boundary to push back on scope creep.
• Support and success tooling. Explicit process definitions make "where is this record stuck?" answerable by support and success teams, and make state-distribution reconciliation reporting possible. That is a product-quality decision, not just an engineering one.
• Sequencing: a phase-two enabler, not a phase-one deliverable. It unblocks later workflow features by giving them a common model, but it is not the thing we ship first. Schedule adoption after we have one bounded process to prove it on.
• An explicit non-decision. This is not the tool for durable, distributed, cross-service orchestration. Deciding we need Temporal/Camunda-class infrastructure is a different and much larger platform commitment. Conflating the two is the classic evaluation error here, and saying so out loud is itself a product decision worth recording.

Caveat to carry into every product conversation: the only release is 0.0.1 (April 2023), with no substantive release notes, 66 stars, zero dependents, and a single maintainer. Treat its description as a name-and-scope-level signal, not a validated capability set. Do not put it on a critical path on the strength of a README.

When to Consider This Package

Consider it when:

• The domain genuinely has multi-state, multi-actor processes where transition rules are business rules — approvals, claims, KYC, fulfillment — not incidental status checks.
• We are on a Laravel/PHP stack and want the process definition versioned in the same repo, reviewed in the same PRs, and tested with the same tooling as the app.
• We want in-process orchestration — no extra runtime, no separate deployment, no new on-call surface.
• We can accept a pre-1.0 dependency, will pin the version exactly, and will wrap it behind our own interface so upgrades and abandonment stay contained.
• The process needs to be readable by non-engineers (ops, compliance, support) as a first-class artifact rather than inferred from code.
• We have a bounded, low-traffic pilot process with no external side effects to prove it on — ideally one already implemented with ad-hoc status checks.

Look elsewhere when:

• We need durable, long-running, cross-service orchestration with retries across boundaries. A dedicated engine is correct; a single-app package becomes a liability.
• The "process" is two or three states on one model. A plain enum plus a guard method is cheaper, dependency-free, and won't need migrating.
• We require vendor support, an SLA, or a security-review trail. At 0.0.1 none of that exists.
• We need visual authoring or BPMN import. This is a code-level tool.
• The team has no appetite to own an abstraction layer around a young package — without that wrapper we inherit upgrade risk directly in domain code.
• We need confirmed transition history/audit guarantees or concurrency safety (row locking on double-transitions). Release notes establish neither; verify against source before committing.

Gate before promotion: a documented release with real notes, a source read of the transition/guard/persistence model, and one production-shaped pilot behind a feature flag. Until then this stays a spike.

How to Pitch It (Stakeholders)

For executives — one paragraph: We are evaluating a small open-source Laravel component that lets us express business processes — approvals, order lifecycle, onboarding — as explicit, named definitions in our own codebase instead of ad-hoc status flags scattered across features. The value is real but indirect: lower cost and risk on a recurring class of roadmap work, fewer bespoke state machines, and better answers when support asks "where is this stuck?" The risk is maturity — version 0.0.1, no substantive release notes, single maintainer, zero dependents, no stability promise. Recommendation: do not commit it to the critical path now. Pilot it on one bounded internal workflow, then revisit at a documented release or 1.0. Evaluation cost is a few engineering days; the cost of adopting too early is rework inside domain-critical code.

For engineering — the honest framing: This package proposes to own the state-machine/transition layer we keep rewriting. The trade is clear: we gain a shared vocabulary and less bespoke logic; we take on a pre-1.0, single-maintainer dependency in a domain-critical area with high blast radius on core entities. Mitigation is non-negotiable — put it behind our own thin interface (ProcessRunner / TransitionService), pin the exact version, and require tests around every process definition. Also confirm the actual need first: in-process orchestration (this package) versus durable cross-service orchestration (not this package). That distinction decides the entire evaluation.

What we need before promotion: a documented release with real notes; a source read of the transition/guard/event/persistence model; answers on audit history, transaction boundaries, queued or long-running transitions, and concurrent-transition handling; and one production-shaped pilot behind a feature flag, shadow-compared against existing logic. Until then, this is a spike, not a dependency.