Product Decisions This Supports
- Desktop as a distribution channel — build vs. buy vs. defer. The core decision this package informs is whether a Laravel/Filament team can ship a Windows/macOS/Linux desktop client without hiring Electron/React specialists. NativePHP does the packaging; NativeKit supplies the opinionated scaffold. That's a hiring-and-timeline decision, not a library decision, and it's the one worth taking to a roadmap review.
- Admin surface: commodity or differentiator? Filament + a pre-wired user/admin split means the back office is scaffolded on day one. Decide explicitly whether internal admin is a place to spend engineering months (it usually isn't) or a place to differentiate.
- Candidate use cases to evaluate against: internal operations tooling for non-technical staff, offline-first field apps, a desktop companion to an existing SaaS (local file access, no browser tab), kiosk/point-of-sale front ends, and agency client deliverables where time-to-first-demo is the billable metric.
- Standardize-an-org-template decision. If two or more products will live on the same stack, a vetted starter kit is a real productivity lever. This one is a candidate to evaluate, not a default to adopt.
- Decisions it does not support: core product differentiation, pricing, or anything requiring an audited, vendor-backed dependency. Treat it as scaffolding, never as infrastructure on the critical path.
When to Consider This Package
Consider it when all of these hold: the team is already Laravel/Filament-fluent; you have a greenfield or greenfield-adjacent app rather than an established codebase; desktop distribution is a genuine near-term requirement, not a someday idea; the deliverable is internal or prototype-grade; and someone owns the fork.
Look elsewhere when any of these hold:
- Adoption signal is thin. Two stars and a single maintainer is not a community; it's one person's project. There is no LTS, no deprecation policy, and no upgrade guide in evidence.
- Version discipline is a problem. A Guzzle 7→8 major landing in a patch release, plus a model/resource/login refactor to external user/admin packages under a patch version, means
^3.3 will absorb breaking changes silently. That's tolerable for a prototype and disqualifying for a system with a support contract attached.
- The package version tracks the Filament version. Lockstep coupling means your Filament upgrade cadence is now the vendor's cadence.
- Positioning doesn't match reality. The package description advertises "zero-dependency helpers, drop into any Laravel project," while the repo is a Laravel 13 + Filament 3 + NativePHP starter kit with a real transitive dependency graph. Two contradictory self-descriptions is a documentation-ownership red flag — budget for reading source, not READMEs.
- Compliance, security review, or procurement requires a named vendor, a CVE process, or contractual support.
- You need what a starter kit doesn't give you anyway: code signing, notarization, auto-update channels, crash reporting, telemetry, licensing/entitlement enforcement, or offline sync. None of that is in scope here.
How to Pitch It (Stakeholders)
To executives: "There's a low-cost way to test whether our PHP team can ship desktop software without a new front-end stack or new hires. It's a scaffold, not a platform bet. I'm proposing a two-to-three-day spike against one real internal tool, with a go/no-go on measured time-to-first-installable-build. Downside is bounded: the code is ours to fork and the package is disposable."
Lead with velocity and avoided hiring cost. Do not lead with the package name — lead with the capability. Be explicit that the dependency itself is not being endorsed; the reference architecture is.
To engineering: Frame it as a starting point to be forked and pinned, not a dependency to be trusted. Ask for three commitments before the spike: pin the version and the matching Filament constraint together; inventory every class you'd override (User model, login, resources) before touching the lockfile; keep the upgrade in an isolated commit so a rollback doesn't drag unrelated dependency movement with it. Expect churn — patch releases here routinely carry runtime dependency movement, so patch bumps get reviewed, not auto-merged.
To procurement/security: single maintainer, funding links rather than a support contract, no published security or deprecation policy. If the spike succeeds, the path forward is an internal fork with a named owner, not an ongoing upstream dependency.
Success criteria for the spike: an installable build on at least one OS, a working admin login and one CRUD resource, and a written estimate of ongoing fork maintenance. If the estimate exceeds the cost of an off-the-shelf alternative, kill it and move on.