Servicedeskkitv5 Laravel Package

Product Decisions This Supports

• Frontline service-desk build vs. buy. This package is a Filament-based helpdesk/service-desk kit (tickets, users/admins, admin panel login). The 5.9.0 release moves it further toward a composable "kit" model by pulling user/admin models, resources, and login out into dedicated packages (PR #98) rather than shipping them inline. That is a decision-relevant signal: it lowers the cost of adopting the helpdesk surface while keeping identity/auth concerns in separately versioned dependencies you may already standardize on.
• Platform upgrade timing. The Filament bump to v5.9.0 plus PHPStan now running on PHP 8.4 (PR #97) means the maintainer is tracking the current Filament major line and validating against PHP 8.4. If your roadmap includes a PHP 8.4 migration or a Filament v5 adoption, this release reduces the "will this starter kit hold us back" risk — a useful data point for sequencing that upgrade work.
• Build vs. extend for internal ops tooling. Because the package is now thin over upstream user/admin packages, the realistic PM framing is "extend" rather than "build." That shifts effort from scaffolding (models, resources, login screens) to your differentiated workflows (SLA logic, routing, reporting). Budget accordingly: less greenfield build, more integration and domain modeling.
• Dependency-upkeep cost as a roadmap line item. The release is dominated by CI hygiene — standardized Dependabot config, update-changelog workflow, test workflow, and a batched 3-package composer dependency bump. This tells you the project's maintenance is largely automated. Plan for routine minor-version churn on a cadence rather than large one-off upgrade projects.
• Use cases it fits. Internal helpdesk/ITSM front ends, support ticketing for small teams, and admin back-office panels where Filament conventions are acceptable. It is not a fit for customer-facing, high-scale, or heavily customized UX products.

When to Consider This Package

Adopt (or pilot) when:

• Your team is already on, or committed to, Filament v5 and PHP 8.4-capable infrastructure. Version alignment here is the single biggest adoption gate.
• You need internal admin/agent-facing tooling rather than a public-facing product — Filament's resource/panel model is optimized for back-office productivity.
• You are comfortable inheriting upstream user/admin packages for models, resources, and login. Post-#98, identity and auth surface area is owned elsewhere; if your security review requires controlling that code directly, you must vet those dependencies as first-class components.
• You want to de-risk scaffolding, not own it. Best value is teams of 1–5 engineers who'd otherwise spend weeks on CRUD, auth, and panel setup.
• You can absorb frequent minor releases. The Dependabot-driven cadence means regular dependency bumps flowing through your lockfile; you need a routine to review and merge them.

Look elsewhere when:

• You need a customer-facing or omnichannel support product (portal, email ingestion, SLA engines, omnichannel routing) — this is a starter kit, not a full ITSM platform.
• Your stack is pinned to Filament v3/v4 or PHP < 8.3, or you're standardized on Livewire-free or non-TALL front ends.
• You require long-term support guarantees, an SLA, or vendor accountability. This is a single-maintainer OSS project; the changelog is CI-heavy and the release history is version-bump driven. Treat it as a starting point you fork and own.
• You need auditable, security-reviewed auth with no third-party model/resource packages in the critical path.
• Your product differentiation is the support UI itself — inheriting Filament's conventions will fight you.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is an open-source Laravel/Filament starter kit for building an internal service desk. The 5.9.0 release is a maintenance release, not a feature release: it bumps the underlying Filament UI framework to v5.9.0, modernizes the project's automated testing and dependency-update pipelines, adds static analysis on PHP 8.4, and separates user/admin identity into dedicated packages. Net effect for us: it's cheaper to stand up the ticketing back office than to build it, it keeps pace with current framework versions so we don't inherit an upgrade liability, and it carries no licensing cost. The trade-off is single-maintainer risk and a dependency on Filament's design conventions — so we should treat it as an accelerator we fork and own, not as a supported platform.

For engineering leads: The substantive change in 5.9.0 is PR #98 — models, resources, and login now come from upstream user/admin packages instead of living in the kit. Treat this as a potential breaking change against 5.8.x: customizations touching the previous User/Admin models, Filament resources, or the login flow will need to be re-pointed at the new package-provided classes, and those packages now enter your security-review and upgrade surface. The remaining commits are non-functional: standardized Dependabot/test/update-changelog workflows, PHPStan on PHP 8.4, and a three-package composer bump. Recommended next step is a short timeboxed spike — install 5.9.0 in a scratch branch, diff the auth/model wiring against 5.8.4, and confirm our Filament and PHP versions are compatible before committing to anything on the roadmap.