Filament Tour Laravel Package

Product Decisions This Supports

• Activation and time-to-first-value. The core value is onboarding: guided tours cut the "blank admin panel" problem for new users without a support call or a docs page. This directly supports decisions about onboarding investment — a tour is roughly a day of engineering plus content, versus CS-led onboarding or a help center build.
• Support-cost structure. Two distinct mechanisms here: one-shot tours (Tour/Step, gated once per browser via local storage) for first-run education, and persistent Highlight icons that sit next to any element as contextual help. The split matters — tours handle launch, highlights handle long-tail "what does this field do" tickets. Decide which problem you're actually buying for before scoping.
• Content operations vs. deploys. Tour::make(url:) / Tour::make(json:) lets tour definitions live in a JSON file in storage or behind a URL, which means tour copy, ordering, and button labels can change without a code deploy. That's a real roadmap fork: keep tours as developer-authored PHP in page classes (fast, type-safe, low governance) or move to JSON and treat tour content as an editorial asset. The latter implies ownership, review, and a place to store it.
• Where UI complexity gets absorbed. If a panel is hard enough to navigate that it needs tours, that's also a signal about navigation and information architecture. Tours are a mitigation, not a fix — worth pairing with a decision to revisit the underlying screens.
• Feature launch announcements. The event API (filament-tour::open-tour, filament-tour::open-highlight) plus dispatchOnNext means tours can be triggered from a button, a changelog modal, or a post-signup redirect — useful for announcing new features to existing users, not just new-user onboarding.
• Build vs. buy. In-house equivalent means registering DriverJS assets in Filament, bridging Livewire events, serializing steps, and gating on local storage — realistically one to two developer-weeks to reach parity, plus ongoing maintenance. At MIT license and one composer require, buy is clearly right if the maintenance risk is acceptable (see below).

Gap to be aware of: there is no built-in analytics. The "show once" flag lives in the browser's local storage, not on the user record — so tour state doesn't follow a user across devices, and it resets when they clear storage. Completion, skip, and abandonment rates are not captured. Any decision that depends on measuring onboarding effectiveness needs instrumentation added on top, or a different tool.

When to Consider This Package

Consider it when:

• You already run a Laravel Filament panel (v2 through v5 are all supported, with version-pinned installs per major).
• You need a guidance layer quickly and your team is comfortable owning a small dependency that may go unmaintained.
• Tours can be authored by developers inside page classes via the HasTour / HasHighlight traits — no database schema, no migrations, no new service.
• ->visible(Closure) is enough for targeting (e.g., "only show if the user has zero posts"), and the once-per-browser gate is acceptable.
• You're willing to fork or vendor. The README opens with the maintainer stating they can no longer continue fixing and improving the package. That is the single most important fact in the assessment. With 124 stars and zero dependents, there is no community to absorb that risk and no broad bug-report corpus to lean on.

Look elsewhere (or build thin in-house) when:

• Onboarding effectiveness must be measured — completion funnels, per-segment skip rates, per-user state that survives device changes.
• You need segmented campaigns, A/B-tested tours, or scheduling without shipping code.
• Accessibility compliance is a hard requirement. DriverJS focus management and ARIA behavior should be audited, particularly for keyboard-only and screen-reader users, before committing.
• Tours are marketing-owned content needing CMS workflow, localization at scale, or approval gates.
• You require vendor SLAs, security patch commitments, or support for a Filament major that doesn't exist yet (v6 is not promised).
• Multi-tenant or enterprise deployments where a broken tour in production is customer-visible and the fix depends on one volunteer.

How to Pitch It (Stakeholders)

For executives: An MIT-licensed, low-cost way to add in-app product tours and contextual help to our admin panel. Adopting it is roughly a day of engineering plus content authoring, with no per-seat licensing and no database changes. The upside is faster user onboarding and fewer "how do I…" support tickets. The risk is concentrate: it's maintained by a single developer who has publicly stated they can't keep up. Mitigation is to pin the version and keep our usage behind a thin internal abstraction — if it dies, we replace the internals without touching page code. Recommended framing: adopt as a fast, reversible experiment with a time-boxed review, not as a long-term platform commitment.

For engineering: Install is composer require jibaymcs/filament-tour:"^N.0" matching the Filament major, register FilamentTourPlugin::make() on the panel, and use HasTour / HasHighlight on the pages you want covered. Tours are composed from fluent Tour::make() / Step::make() objects with CSS-selector targets; a built-in selector picker (Ctrl/Cmd+Space, disabled in production) speeds authoring. Config and views are publishable for customization. No migrations, no schema, no new services. Two engineering asks: wrap it behind our own contract so a fork or swap is a contained change, and audit keyboard/screen-reader behavior of the tour overlay before it reaches customers.