Filament Kanban Board Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-panel board UIs. A Filament plugin that renders records as a draggable Kanban board (status = column, drag = status/order change) collapses what is typically 2–6 weeks of UI work — board layout, drag-and-drop persistence, ordering, filters, and modal editing — into a composer require plus a resource configuration. The PM decision is whether the board is a differentiator (build) or table stakes plumbing (buy/adopt).
• Roadmap sequencing for internal operations tooling. Unlocks a credible "boards" story for CRM pipelines, support ticket triage, editorial calendars, onboarding checklists, and sprint/backlog views without committing a squad to a bespoke front end. Useful for hitting a demo or pilot date.
• Feature surface to scope (and to not scope). Because the plugin covers the drag-between-columns primitive, the PM can defer swimlanes, WIP limits, analytics rollups, and multi-board aggregation to later phases and validate demand first.
• Adoption risk budget. The package is pre-1.0 (0.2.x) and maintained by a single small publisher; release 0.2.5 ships with no human-written notes, only a diff link. That is acceptable for internal admin tooling on a pinned version, but it is a blocking constraint for anything customer-facing or contractually SLA-bound.
• Standardization/consolidation. If multiple internal apps already use Filament, adopting one board plugin reduces divergent in-house implementations and the long-term maintenance tail that comes with them.

When to Consider This Package

Consider it when:

• The application is already on Filament (v3-era) and the board lives inside the admin panel, behind authentication, for a known internal audience.
• The workflow is genuinely columnar: a bounded set of statuses, records that move left-to-right, and manual ordering that users expect to drag.
• The team accepts pre-1.0 semantics — minor version bumps may carry breaking changes — and can pin versions in composer.json with a reviewed upgrade cadence.
• Time-to-first-demo matters more than long-term UI ownership, and the board is supporting infrastructure rather than a headline product feature.
• You can absorb the plugin's code into your own repo (fork/vendor) if the maintainer goes quiet; the surface area is small enough that this is realistic.

Look elsewhere (or build) when:

• You need real-time multi-user collaboration, presence, conflict resolution, or live board sync — this is not that.
• You need swimlanes, WIP limits, cross-board/portfolio rollups, dependency arrows, or capacity/velocity analytics; expect to build these yourself on top.
• The board is customer-facing or revenue-critical and requires a vendor SLA, security review, accessibility conformance, or a documented support channel.
• Your Filament major version is outside the plugin's supported range — verify compatibility before any roadmap commitment, since Filament majors move fast and plugins lag.
• You require fine-grained per-column or per-card permissions, audit trails on moves, or complex state machines (approvals, gates, transitions with side effects). Model those in your domain layer first; the board should be a view, not the source of truth.
• You are not on Filament at all — the value proposition is largely the Filament integration, and a standalone JS board (or a generic drag-and-drop library) is a better fit.

Note on 0.2.5: a patch release with no substantive notes beyond a changelog diff. Treat it as routine maintenance; it neither unlocks new roadmap options nor introduces documented breaking changes. It does, however, reinforce the operational requirement to pin the version and review diffs before upgrading rather than tracking ^0.2 blindly.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, open-source add-on that gives our admin panel a drag-and-drop Kanban board — the same interaction pattern users expect from Trello or Jira — for roughly the cost of an integration ticket instead of a multi-week build. It removes a recurring "can we get a board view?" request from the roadmap and lets us test whether pipeline/board workflows are worth investing in further, at low cost and low commitment. The trade-off is that it is a pre-1.0 package from a small maintainer: fine for internal tooling, not something we would put in front of customers or build a contractual commitment on. Recommendation: adopt behind the admin panel, pin the version, and revisit if we outgrow it.

For engineering:

• Scope is narrow by design: it renders a board and persists drag-driven status/order changes. Everything else — permissions, transition rules, audit logging, swimlanes, metrics — stays in our domain layer.
• Risk is maintainer risk, not technical risk. Mitigations: pin the exact version, review the changelog diff before bumping (0.2.5 shipped with no written notes), keep the integration behind a thin internal abstraction so a fork or replacement is a contained change, and confirm Filament version compatibility up front.
• Success criteria for the pilot: board loads within our admin performance budget at realistic record counts, drag-and-drop persists correctly under concurrent edits, and no Filament upgrade is blocked by the dependency. If any of those fail, we fall back to a filtered table view with a status dropdown — the workflow survives, only the interaction degrades.

For the product team: the board makes status visible and changeable in one gesture, which is the actual behavior change we want. Do not promise swimlanes, WIP limits, or analytics in the first release; validate that users move cards before funding the next layer.