Filakitv5 Laravel Package

Product Decisions This Supports

Build vs. buy on the admin/back-office layer. Filakit is a Filament v5 starter kit — authentication, user/admin models, resources, and login scaffolding come pre-wired. The decision it informs is whether your team spends 2–6 engineer-weeks standing up an internal admin panel from scratch or starts from a maintained scaffold and spends that time on domain logic instead.

Time-to-first-demo and roadmap sequencing. If back-office CRUD, user management, and role separation (user vs. admin) sit on the critical path for a launch or a pilot, adopting a starter kit compresses the front of the schedule and lets you re-sequence differentiation work earlier.

Architecture choices around multi-audience auth. The 5.10.1 change "Use user/admin packages for models, resources and login" is the substantive item in this release. It moves the user and admin surfaces out of the kit's core and into discrete packages. Product impact: two distinct user populations (end customers vs. internal staff) are now a first-class, separately ownable concern — which is exactly what you want if you plan to give internal ops a different surface from customers, or if you expect one of those surfaces to be replaced later.

Security-patch cadence as a product-risk input. Three of the seven changes (shell-quote patch, source-map-js override, pnpm override relocation) are dependency hardening, and two are automated dependency bumps. This tells you the maintainer runs automated updates and patches transitive JS dependencies — a positive but not sufficient signal for a supply-chain review.

What this release does not decide for you. It contains no new product capabilities, no breaking API changes called out, and no deprecations. It is a maintenance release. Do not use it to justify a roadmap change; use it to confirm the dependency is being kept current.

When to Consider This Package

Adopt when:

• You are building on Filament v5 and want a headless-ish starting point rather than the official Filament panel generator alone.
• You need two distinct actor types (customer-facing user + internal admin) with separate models, resources, and login flows — the new package split aligns directly with that.
• Your team is Laravel/PHP-fluent and comfortable owning a fork. A starter kit is a starting point, not a dependency you consume passively.
• You can absorb single-maintainer risk. The changelog is dominated by one contributor plus Dependabot. There is no evidence of a second reviewer or a release process independent of that person.
• Version discipline is acceptable: this release jumps 5.8.4 → 5.10.1 with a changelog that is largely automated. Semver here is a version number, not a compatibility contract.

Look elsewhere when:

• You need an official, support-backed foundation — Filament's own starter kits or a first-party Laravel kit carry materially lower maintenance and supply-chain risk.
• You are not on Filament v5, or you are pinned to an older Filament and cannot absorb the coupling.
• Your admin surface is small enough to hand-build — a starter kit's value collapses if you will rewrite most of the resources anyway.
• You require auditable release notes and a security disclosure process. This release does not demonstrate one.
• You need multi-tenancy, audit logging, or compliance controls out of the box; assume you build those yourself.

How to Pitch It (Stakeholders)

To executives (one paragraph): Filakit is an open-source Laravel/Filament starter kit that gives us the login, user management, and admin panel scaffolding for free instead of building it. This release (5.10.1) is a maintenance update — it tracks Filament to the current version, splits the user and admin surfaces into separate packages so we can evolve internal tools and customer accounts independently, and patches several transitive front-end dependencies. There are no new features and no breaking changes. The real decision in front of us is not this release; it is whether we accept the risk of building on a single-maintainer open-source project. My recommendation is to adopt it as a forked starting point we own, not as an upstream dependency we track — that converts the maintainer-risk question into an ordinary code-ownership question.

To engineering (summary): Upgrade is low-risk: dependency bumps, CI auto-merge for Dependabot, and pnpm overrides moved into pnpm-workspace.yaml with security patches applied to shell-quote and source-map-js. The structural change is PR #160, which delegates user/admin models, resources, and login to dedicated packages — review this before upgrading if you have customized the generated auth scaffolding, since your customizations likely live in files that have moved. Budget a half-day for the upgrade plus a review of any local overrides, and confirm the pnpm override relocation does not conflict with our lockfile strategy.

Framing to use in the decision meeting: treat this as buy-then-own. Score it on how much scaffolding we delete from our own backlog, and gate adoption on a supply-chain review of the maintainer and the dependency tree — not on the contents of this release.