Filament Kanban Laravel Package

Product Decisions This Supports

• Build vs. buy for internal support operations. A Filament-native help desk lets you evaluate replacing per-seat SaaS (Zendesk, Freshdesk, Intercom) with a module that lives inside the admin panel your team already uses — no second login, no separate data store, no per-agent licensing.
• Roadmap placement of support workflows. The 2.0.1 fix references a board view, which points to an agent-facing triage surface (status/kanban-style queue) rather than a customer-facing portal. That shapes scope: agent-side triage now, public intake/portal later, if at all.
• Upgrade and platform decisions. Shipping the board layout as a stylesheet registered through FilamentAsset indicates the 2.x line is aligned with the modern Filament asset pipeline. This is a signal for teams deciding whether to standardize on Filament for back-office tooling.
• Host-app build ownership. The bug class here — vendor Blade views purged by Tailwind because host apps never scanned them — is a recurring integration tax for any package that ships views. The fix moves CSS ownership into the package, which lowers the configuration burden on consuming apps and makes the dependency safer to adopt in locked-down CI/CD pipelines.
• Fork vs. consume. Because styling is now self-contained, customizing the board means deliberately overriding published assets rather than editing a Tailwind config. That is a cleaner contract, and it makes the "vendor it and patch it" option more predictable.

When to Consider This Package

Consider it when:

• You are already running Filament and want ticketing inside the existing panel rather than a bolt-on SaaS.
• Your support operation is small-to-mid volume, agent-centric, and cost- or data-residency-sensitive (self-hosted, no third-party processor).
• You need to ship an internal MVP quickly and are comfortable extending or forking Blade views.
• You have a working Tailwind build pipeline and want a dependency that does not require you to add vendor/ paths to your content globs.
• You can absorb single-maintainer risk on a community package — plan a fork contingency rather than a support contract.

Look elsewhere when:

• You need multi-channel intake (email, chat, voice), formal SLAs, CSAT reporting, or a polished end-customer portal at scale — that is a Zendesk/Freshdesk/Intercom conversation.
• You are pinned to an older Filament major version; the FilamentAsset registration implies a newer Filament baseline. Verify compatibility before committing a roadmap slot.
• You require vendor SLAs, security review sign-off from a commercial entity, or a guaranteed upgrade path.
• Your board UI requirements are heavy — deep visual customization against a package-owned stylesheet means override maintenance on every release.

Upgrade note for evaluators: 2.0.1 changes where board CSS comes from. Host apps that previously added this package's vendor views to their Tailwind content globs should remove those entries and rebuild, then re-run visual QA on the board to catch duplicated or conflicting utility classes.

How to Pitch It (Stakeholders)

For executives: This is a self-hosted help desk that runs inside our existing admin panel, which gives us a credible path off per-seat support SaaS — lower run-rate cost, support data stays in our own infrastructure, and agents work in one tool instead of two. Release 2.0.1 is a quality fix, not a feature release: it makes the board's styling self-contained so it renders correctly in production builds. That eliminates a "looks fine in dev, breaks in prod" failure mode that would otherwise have surfaced after we rolled it out to agents.

For engineering: 2.0.1 replaces raw Tailwind utility classes in the board layout with a stylesheet registered via FilamentAsset. The root cause was that host applications never scanned the package's vendor views, so production Tailwind builds purged the layout and the board degraded to an unstyled list. Upgrading is low-risk but not zero-touch: remove any package vendor paths from tailwind.config content globs, rebuild assets, clear Filament's asset cache, and visually verify the board in a production-mode build. Treat the package as a community dependency — pin versions, keep our ticket domain model behind our own abstraction layer, and budget for a fork if maintenance lags. Recommended next step: pilot on one support queue, measure fit against our ticket states and assignment rules, then decide on broader rollout versus a commercial alternative.