Formflow Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for multi-step form orchestration. FormFlow provides the state machine around multi-step forms (step navigation, conditional transitions, data carry-over) so engineering can buy the flow logic and spend build effort on the UI and business rules instead. This is the primary decision the package informs.
• Feature feasibility for wizard-style UX. Concrete use cases it de-risks: onboarding/signup wizards, checkout and quote funnels, multi-page application or KYC forms, internal approval/intake flows, and any "save and resume later" form experience.
• Roadmap sequencing for workflow features. If your backlog contains "guided form flows," "dynamic branching questionnaires," or "resumable forms," this package sets a floor on effort — it converts an open-ended design problem into an integration problem with a known dependency surface.
• Architecture choice between server-rendered flows vs. client-side wizards. Adopting FormFlow is implicitly a decision to keep flow state and transitions server-side. That constrains later decisions about SPA routing, offline support, and client-side validation ownership, so treat it as an architecture decision, not a library decision.
• Dependency-risk posture. Version 0.4.x is pre-1.0 with a single primary maintainer. The product decision this supports is whether to run a scoped spike (reasonable) versus commit a customer-facing funnel to it (not yet justified).

When to Consider This Package

Consider it when:

• You are on Symfony, not Laravel. This is yceruto/formflow-bundle — a Symfony bundle built on the Symfony Form and Workflow components. It is not a Laravel package and has no Laravel service provider, facade, or Eloquent integration. In a Laravel codebase, "consider" really means "evaluate as a reference implementation," not "composer require."
• Your flows are genuinely stateful and branching — steps whose order, availability, or destination depends on prior answers. For a fixed 3-step linear form, this is over-engineering.
• Your team already uses Symfony Form types and wants the flow layer to compose with existing form definitions rather than replace them.
• You need server-side flow state that survives a page reload or a user returning days later, and you want that logic in PHP rather than duplicated in JavaScript.
• You are comfortable pinning an exact version and reviewing diffs on upgrade while the API is still 0.x.

Look elsewhere when:

• The host application is Laravel. Livewire, Inertia, or a plain session-backed controller flow will be cheaper than pulling Symfony components into a Laravel app; the impedance mismatch usually exceeds the value of the reused logic.
• The product needs a rich client-side wizard (instant step transitions, offline drafts, complex conditional rendering). A server-round-trip flow engine fights that requirement.
• You need vendor support, an SLA, or a large hiring pool. This is a small, single-maintainer open-source project.
• You need API stability guarantees. Pre-1.0 semver means minor releases may break you.
• The flow is trivial — two or three steps with no branching. A switch statement is more honest and more maintainable.

On v0.4.2 specifically: this is a maintenance patch that syncs FormFlow fixes from Symfony (PR #10). No new features, no deprecations, no breaking changes. It is a positive but low-weight signal — it shows the bundle is tracking upstream fixes rather than drifting — and it does not change any of the adoption criteria above. It reinforces the "pin and review diffs" guidance rather than relaxing it.

How to Pitch It (Stakeholders)

For executives: This is a small open-source PHP component that supplies the "which step comes next" logic for multi-step forms — onboarding, checkout, applications, internal intake. The v0.4.2 release is routine maintenance: bug fixes carried over from the upstream Symfony project, no new capability and no compatibility risk. The strategic read is that the capability is cheap to prototype but not yet cheap to depend on: it is pre-1.0, maintained by essentially one person, and built for Symfony rather than our Laravel stack. Recommendation is a time-boxed spike to validate the flow model and produce a build-vs-buy estimate — not a production commitment. If the spike succeeds, we own the UI and business rules and rent only the orchestration; if it fails, we have a clear spec for building the same state machine in-house in a few weeks.

For engineering: FormFlow is a Symfony bundle on top of Symfony Form and the Workflow component — treat it as design input for Laravel, and as a genuine candidate only in a Symfony service. v0.4.2 contains a single change: FormFlow fixes synced from Symfony. No API changes, so upgrades from 0.4.1 are safe. Two asks: (1) pin the exact version (0.4.2) and read the changelog on every bump, since 0.x minors can break; (2) in the spike, verify the parts that usually hurt — persisting partial form data across sessions, conditional transition rules that depend on submitted answers, and how much flow configuration ends up in YAML/PHP versus leaking into controllers. Report back on whether the transition model maps cleanly onto our domain, because that answer determines build vs. buy more than any benchmark will.