Core Laravel Package

Product Decisions This Supports

• Build vs. buy for workflow/orchestration: SeviaFlow Core is positioned as a reusable Laravel-native flow/workflow layer. The first beta makes it evaluable — it is now a legitimate input to a build-vs-buy conversation for teams who would otherwise hand-roll state machines, approval chains, or multi-step pipelines.
• Roadmap sequencing (evaluation, not commitment): The only decision this release reliably supports is "should we spend a timeboxed spike on this?" It does not yet support decisions about migration, platform standardization, or production rollout.
• Feature-level fit check: Useful for answering "does this package's model of a flow match ours?" against one real, concrete use case in your backlog — not for abstract architecture planning.
• Risk posture for a greenfield module: If a workflow feature is early enough in discovery that a dependency swap is cheap, trialing here is low-cost. If the feature is on a near-term release train, this is the wrong input.
• Explicitly NOT supported yet: production adoption, SLA-backed commitments, long-term API stability assumptions, or displacing an existing workflow solution. A beta with an explicit "APIs and package behavior may change" warning cannot underwrite those decisions.

Evidence gap to flag: the release notes contain no changelog detail, no feature list, no migration notes, and no supported-version matrix. This assessment is therefore about posture and process, not capability. Capability claims should be re-derived from the repository, tests, and docs during the spike — treat any verbal characterization of features as unverified until then.

When to Consider This Package

Consider it when:

• You have a concrete, bounded workflow need in a Laravel codebase (state transitions, multi-step processes, approval routing) and are currently weighing hand-rolling it.
• Your team can absorb API churn — i.e., you can pin an exact pre-release version and accept a rewrite of the integration surface later.
• You have a spare engineer-cycle for a timeboxed spike (1–2 weeks) behind an internal interface, with a documented exit path if the API shifts or the package stalls.
• You want early influence: beta-stage feedback on a package you might depend on is disproportionately effective, and pre-1.0 is when maintainers are most responsive to design objections.
• Laravel-native integration (service container, config, Eloquent conventions) is a genuine advantage over a generic, framework-agnostic workflow engine.

Look elsewhere when:

• The need is production-critical or revenue-path within the current quarter — a pre-release with declared instability is disqualifying.
• You require vendor support, SLAs, security review sign-off, or a published deprecation/versioning policy. None of that exists at 0.1.0-beta.1.
• Your workflow needs are simple enough that a small internal state machine or an established, stable package is cheaper than adopting an unproven dependency.
• You cannot tolerate a dependency whose API surface may change before 0.1.0 stable — this is stated plainly in the release notes.
• Procurement/licensing terms have not been confirmed; do not assume a license or governance model from the release notes.

How to Pitch It (Stakeholders)

For executives (one paragraph): A Laravel workflow package called SeviaFlow Core has published its first beta. This is an evaluation milestone, not an adoption milestone — the maintainers explicitly state the API and behavior may change before stable. The recommended action is a small, timeboxed engineering spike with no production commitment, costing a fraction of one engineer-cycle. The upside is potentially replacing custom workflow code we would otherwise build and maintain ourselves; the downside is capped, because we deliberately wrap it behind an internal interface so it can be removed. Decision requested: approve the spike, not the dependency.

For engineering leads: Treat 0.1.0-beta.1 as a research artifact. Pin the exact version, do not allow it to resolve by range, and do not let it enter the main application's dependency graph until it is behind our own abstraction. The spike should answer three questions: (1) does its flow model match our domain without contortions, (2) how large is the surface we would have to own if the maintainer disappears, and (3) what does the test suite and issue tracker actually say about maturity — the release notes do not. Report back with a recommendation and an estimated migration cost if the API changes.

Framing to avoid: do not present this as "we are adopting a workflow engine." The accurate framing is "we are pricing an alternative to building one," and the beta status is the reason the price is low and the commitment is zero.