Product Decisions This Supports
- Build vs. buy for guided workflows. Quest provides a Laravel-native abstraction ("quests" composed of ordered steps/tasks with per-user progress) that would otherwise be hand-rolled as bespoke state columns, status enums, and progress-tracking controllers. This is the classic "three days of glue code that nobody wants to own" decision — the package lets you buy that layer and spend the sprint on the actual onboarding content.
- Roadmap sequencing for activation and onboarding. If activation, guided setup, or in-product education is on the roadmap, this is a candidate dependency for shipping a first version in weeks rather than quarters. It supports time-boxed experiments (e.g. "does a 5-step setup checklist improve week-1 retention?") without committing to a workflow platform.
- Feature gating and progressive disclosure. Quest completion state is a natural signal for unlocking features, surfacing empty-state guidance, or triggering lifecycle messaging — decisions that otherwise get spread across feature flags and ad-hoc
completed_at columns.
- Reduce bespoke surface area / tech-debt paydown. Every custom progress-tracking implementation is a maintenance line item. Adopting a maintained abstraction is a de-risking decision, not a feature decision, and should be framed that way in prioritization.
- v4.0.0 specifically: configuration flexibility as a decision input. The headline change — added configuration options — directly reduces the "we'd have to fork it to make it fit" objection. Configurability lowers the integration cost estimate and makes the build-vs-buy math favor buying, but the major version bump for a config-only change is itself the signal to weigh: either defaults changed in a way the changelog doesn't spell out, or the maintainer treats majors loosely. Both are material to a dependency decision and should be validated in a one-day spike before committing.
When to Consider This Package
Consider it when:
- The application is Laravel/PHP and the workflow is user-facing and sequential — setup checklists, onboarding journeys, progressive task completion, multi-step guided flows.
- Your team is small and the alternative is custom progress-tracking code that nobody is excited to own.
- You need durable per-user progress (persisted, resumable, queryable) rather than ephemeral UI state.
- You want the flow defined in code by engineers but tuned by product (ordering, step composition, copy) without a redeploy-heavy rewrite each time — the new configuration options in v4.0.0 improve this materially.
- You can pin the version and absorb a major upgrade on your own schedule.
Look elsewhere when:
- You need real orchestration: branching DAGs, parallel branches, compensation/rollback, long-running timers, or human-approval queues. That's a workflow engine (Temporal, Laravel Workflow, or an explicit state machine) — Quest is not that, and forcing it to be will produce an unmaintainable quest graph.
- The requirement is regulatory or audit-facing. You need explicit transition logging, immutability, and a vendor with an SLA; a single-maintainer OSS package is the wrong risk profile for a compliance boundary.
- You're multi-tenant with per-tenant flow definitions, or you need flows authored by non-engineers in an admin UI. Config-file-driven definitions are engineer-facing by design.
- You're not on Laravel, or you're on an unsupported PHP/Laravel version — check the compatibility matrix before scoping anything.
- The quest is genuinely one-shot and trivial (a single boolean "has completed setup"). A column and a middleware is cheaper than a dependency.
On v4.0.0 as an adoption moment: the major bump means you should not adopt casually mid-sprint. Treat it as a fresh evaluation: read the config PR (#13), diff the defaults against v3, and confirm whether existing behavior changes for anyone already on v3. The upside is real — configurability is exactly the gap that blocks adoption in opinionated codebases — and a first-time outside contributor is a modest positive signal for project health. But one PR, one contributor, one line of changelog is thin evidence for a major version, so budget a verification spike rather than assuming the upgrade is cosmetic.
How to Pitch It (Stakeholders)
For executives (30 seconds):
We can either build our own onboarding/progress-tracking system or adopt a small, free, Laravel-native package that already does it. Building costs roughly a sprint of engineering plus permanent maintenance; adopting costs a few days of integration and a version-pinning policy. Recommendation: adopt behind a spike, pin the version, and revisit at the next major. The main risk is not technical — it's that this is a single-maintainer open-source dependency, so we should not put it anywhere near a compliance or revenue-critical path. The recent v4.0.0 release adds configuration options that make it fit our codebase better, which lowers integration cost; it also jumps a major version for a small change, which is why we verify before we commit.
For engineering:
This is a Laravel package that models guided flows as quests made of ordered steps, with persisted per-user progress. It removes the enum-plus-status-column-plus-controller boilerplate we'd otherwise write and re-write for each new onboarding surface. v4.0.0 adds configuration options (PR #13), which means flow composition and behavior can be adjusted without patching vendor code — that was our main objection, and it's now largely addressed. Two asks before we merge anything: (1) review PR #13 and confirm whether the major bump reflects a behavior/default change we need to account for, and (2) pin the version in composer.json and add an upgrade note to the tech-debt log. Do not extend it into branching or parallel workflows — if the requirement grows past a linear sequence, we escalate to a real state machine rather than bending this.
For the product owner:
This unblocks the onboarding/activation work without a platform bet. It is suitable for checklists, setup guides, and progressive feature unlocking. It is not suitable for approval chains, multi-path journeys, or anything an auditor will ask us to produce a transition log for. Approve a one-day spike, not a quarter-long commitment.