Filament Cards Laravel Package

Product Decisions This Supports

• Information architecture / nav redesign. Deciding whether a settings area should stay a deep sidebar tree or become a hub-and-spoke ("Settings home" grid → detail page). This package makes the hub pattern cheap enough to prototype and A/B against the status quo instead of debating it in a design doc.
• Build vs. buy for admin UI. The alternative is 200–400 lines of bespoke Filament page code plus ongoing maintenance. This shifts that to a Composer dependency with an API that mirrors Filament's own (label, description, schema, visible/hidden, columnSpan), so the marginal cost is measured in hours, not a sprint.
• Roadmap sequencing for admin UX. Lets you ship a discovery/onboarding improvement ("users can't find Billing settings") without displacing committed feature work. Good candidate for a fill-in or between-sprint item.
• Multi-tenant / role-scoped surfaces. visible()/hidden() closures plus per-component canAccess() checks mean the same hub renders different card sets per tenant tier or role — a differentiator you can demo to prospects without a new permission model.
• Modular product architecture. Dynamic registration from service providers lets feature modules or first-party packages contribute their own cards, so the hub stays accurate as the app grows instead of rotting into a stale hardcoded list.
• Feature adoption. Auto-discovery means new pages appear on the hub automatically — no PM-maintained list of "don't forget to add this to the settings page."

When to Consider This Package

Adopt when:

• You are on Filament v4/v5, Laravel 11+, PHP 8.2+ and have a real Tailwind build pipeline (the @source line is mandatory, not optional).
• You already have — or are about to create — a Cluster or Resource with 6+ child pages, where the sidebar has become a scroll-and-hunt experience.
• You want the hub page now, with a team of one or two who cannot absorb a component library.
• You need authorization-aware rendering and per-tenant card variation.
• You are comfortable with a small, single-maintainer dependency and can contain it (see pitch below).

Look elsewhere when:

• You need metric/KPI cards — this is navigation, not a dashboard widget. Different problem.
• You are on Filament v3, or need cards outside Filament (public marketing site, email, etc.).
• Procurement requires adoption evidence, dependents, or a support SLA. 12 stars and 0 dependents will not clear a vendor risk review, and you should not pretend otherwise.
• You have a design-system team that will inevitably re-skin the component; you'll be fighting the Tailwind output rather than extending it.
• You cannot rebuild assets, or the deployment pipeline doesn't run npm run build on release.
• You need 3+ years of guaranteed maintenance on the component.

How to Pitch It (Stakeholders)

For executives (30 seconds):

A small, MIT-licensed add-on that turns our admin settings area into a clean grid of clickable cards instead of a long sidebar. It's a UX change only — no data model, no migrations, no new infrastructure — and it respects our existing permissions automatically. If we don't like it, removing it is a one-day revert. Cost is a day of engineering; the payoff is measurably less time lost hunting for settings.

For engineering:

• It is Filament-native by construction: same fluent API, same canAccess() contract, same navigation config. No new mental model, no abstraction layer to learn.
• Auto-discovery (discoverClusterCards() / discoverResourceCards()) reads existing navigation properties, so pages need zero changes — an opt-out property is the only edit most pages will ever need.
• Contained blast radius. The integration surface is two classes (CardsPage and CardItem/CardGroup). We recommend using those and not spreading the discovery hooks broadly across the codebase. That keeps the exit cost at roughly one sprint if we ever need to replace it.
• Vendor risk, stated plainly: 12 stars, 0 dependents, single maintainer, recent but short release history. This is acceptable only because the package is UI-only and substitutable. It would not be acceptable for anything touching persistence, auth internals, or money.
• Two hard prerequisites we must budget for: the @source directive in theme.css and an asset rebuild in CI. Miss either and it ships unstyled.

Recommendation: Timebox a one-day spike on the Settings cluster, ship behind a feature flag or on staging first, and re-evaluate against the custom-build option once we see whether auto-discovery holds up against our real page topology.