Onboard Laravel Package

Product Decisions This Supports

• Naming "activation" concretely — the highest-value output of this evaluation. The package's data model (a JSON onboarded_steps column plus an onboarded_at timestamp on the user) forces the team to enumerate and order the setup steps a successful user takes. The package is just a persistence helper; the decision it enables is "what does a new user do, in what order, and what counts as done?" That's the prerequisite for every activation metric and every onboarding redesign conversation that follows.

• Turning "where do users stall?" into a SQL question. Once steps are named and persisted, questions like "what share of signups complete step 3 within 7 days?" and "which step has the biggest drop-off?" stop being anecdote-driven debates and become queries. That directly informs roadmap priority and lets you argue for onboarding engineering time with numbers.

• Progressive disclosure and feature gating. Supports rules like "don't surface the advanced dashboard until a data source is connected." In self-serve B2B, gating the aha-moment behind a short checklist is a trial-to-paid conversion lever. This package (or its copied schema) makes the gate cheap to implement via a single middleware rather than per-controller checks.

• Scoping a getting-started surface. Setup wizards, checklist widgets, and workspace provisioning flows are recurring asks in self-serve products. This repo is a ten-minute sketch of the underlying model — enough to size and spec the real feature without a discovery cycle.

• Build vs. buy, resolved in an afternoon. The capability is one migration, one trait, and a handful of helpers. The make-or-buy conversation is short: it's a make, and this repo is the spec.

• Explicitly not supported — keep these as separate decisions with separate tooling: experimentation, cohorts, segmentation, lifecycle email nudges, branching flows, step versioning, multiple concurrent onboarding tracks, and replay. Do not let a checklist project quietly absorb any of these.

When to Consider This Package

Consider it as a reference implementation or same-day prototype only:

• You're on a Laravel 8-era codebase and want a throwaway checklist to validate onboarding copy and step ordering with real users this sprint.
• You want a small, auditable example of how to model step completion (trait + completion state + onboarded_at timestamp) before designing your own schema. Three files and ten minutes of reading get you there.
• You need something disposable in a spike branch that will never ship to production.

Do not adopt it as a production dependency:

• Archived since 2020. No security patches, no bug fixes, no maintainer response, no upgrade path.
• The only recent release (v1.7) adds Laravel 8 support and nothing else. Laravel 8 is itself end-of-life, so this narrows compatibility to a version you should be migrating off of — it is not a signal of renewed maintenance.
• Zero dependents. No ecosystem validation, no community forks patching it, no peer troubleshooting corpus. The 434 stars reflect historical interest in a clever micro-package, not current production fitness.
• The surface area is trivial. One migration, one trait, a few helpers. Reimplementation is one to two developer days and removes supply-chain and audit friction entirely.
• Known design gaps a PM should price in: nothing validates or orders step keys (a typo silently creates an invisible step, potentially letting users reach "onboarded" without doing the real work); the JSON column is read-modify-write so concurrent completions can be lost; stale model instances report stale progress; there are no package-level events, so activation telemetry is yours to emit; and isOnboarded() is decoupled from the step list, so adding a fifth step later won't un-onboard existing cohorts and "onboarded" silently means two different things.
• Scores agree: overall 1.91, opportunity 1.65. Not a production candidate.

Look elsewhere (or build in-house) if you need:

• Real product analytics — PostHog, Amplitude, or Mixpanel for event-level funnels, cohorts, and segmentation. A boolean per step is not analytics; a JSON array per user is not a funnel.
• Branching or conditional onboarding logic — a state machine, or Laravel pipelines and jobs, fits better than a flat step list.
• Email nudges, reminders, or in-app messaging tied to incomplete steps — that's lifecycle messaging, not a schema concern.
• Multiple concurrent onboarding tracks, step versioning, or replay — unsupported, and retrofitting means owning a fork.
• An audited, maintained dependency — this is the disqualifier for anything customer-facing on a long-lived codebase.

How to Pitch It (Stakeholders)

For executives: We evaluated calebporzio/onboard as a shortcut for building a getting-started checklist. The capability we actually want is real and worth building — track which setup steps each new user has completed, use that to gate the product until setup is done, and get a measurable activation funnel out of it. The package itself is not a viable dependency: archived since 2020, its last release only widened constraints to Laravel 8 (itself end-of-life), and it has zero downstream users. Adopting it would mean shipping a dead, unmaintained dependency for something that costs one to two developer days to own outright.

Recommendation: do not adopt; use the repo as a design spec and build the equivalent in-house. The valuable output of this evaluation is the data model and the forcing function to name our activation steps — not the code. The in-house version is low cost, near-zero maintenance, removes a supply-chain and audit liability, and gives us clean seams for analytics events and a proper user_onboarding_steps table when we outgrow the flat list.

For engineering: This is a one-migration, one-trait package, so the "buy" half of build-vs-buy is irrelevant — we're really choosing between a two-year-old unmaintained dependency and ~2 dev days of our own code. If we do prototype with it, copy the trait and migration into app/ rather than depending on it, keep the columns out of $fillable, funnel every trait call through a single OnboardingProgress service with a config-driven step registry (the package validates nothing), mark steps from domain event listeners rather than controllers so API and console paths count too, and plan the user_onboarding_steps table as the exit path so removal is a backfill plus a delete rather than a rewrite.