Product Decisions This Supports
- Support & incident triage (highest-value use case). A visible version chip turns every user screenshot and screen-share into a version report. This directly shortens the "which build are you on?" round trip in bug intake — a measurable MTTR input with near-zero build cost.
- Release verification in staging/demo environments. Product and QA can confirm at a glance that a deploy landed in a given panel, without opening a terminal or asking engineering. Useful for UAT sign-off and stakeholder demos.
- Build vs. buy: this is a "buy the idea, own the code" decision. The feature surface is a single header render hook plus a version-resolution chain. Adopting the MIT package is cheaper than a spec, ticket and review cycle if it fits; forking or reimplementing it in-house is a one-to-two-day task. Treat it as a commodity utility, not a platform dependency.
- Versioning discipline as a roadmap input. If the team cannot currently answer "what version is this environment running?" consistently, the gap is a release-process problem, not a UI problem. This package is a cheap forcing function to standardise a single source of truth (config → env → Composer → git tag) — but note the UI chip is downstream of that decision, not a substitute for it.
- Multi-panel / multi-tenant products. The priority-chain source resolution and per-panel colour inheritance suit apps with separate admin, partner or customer panels that ship on different cadences.
- Not a decision driver for: feature flagging, semver gating, entitlement logic or changelog delivery. If a stakeholder asks for "version awareness in the product," clarify whether they mean display (this) or behaviour (a different, larger piece of work).
When to Consider This Package
Adopt when all of the following hold:
- You are already running Filament, and the panel header is the natural place for this signal.
- You want guest-hidden-by-default behaviour and per-panel theming without writing CSS.
- You need a multi-source priority chain (env/config/Composer/git) rather than a single hardcoded value — the main functional differentiator here.
- You are comfortable pinning the version and vendoring/forking if the maintainer disappears.
Look elsewhere, or build in-house, when:
- You are not on Filament — the value is entirely tied to that render pipeline.
- You need the version where incidents actually happen: exception pages, Sentry/APM release tags, API response headers, structured logs, or the footer of outbound emails. A logo chip is cosmetic relative to those surfaces; prioritise them first.
- Maturity/support risk is unacceptable. Three stars, zero dependents and a single maintainer is unproven. There is no support SLA, no security-response track record, and no community to catch regressions on Filament upgrades. For a regulated or high-availability product, this belongs in a vendored fork under your own maintenance, or not at all.
- You already have a design-system header component — you'd be adding a second pattern for a trivial gain.
- You need version enforcement (kill-switch for stale clients, forced-upgrade prompts, migration gating). Out of scope.
Recommendation: timeboxed spike (half a day) in a non-production panel, pinned to an exact version, with a documented fork path. Do not let it into the critical path of a release.
How to Pitch It (Stakeholders)
For executives: A tiny, free, MIT-licensed UI addition that puts the application version in the admin header. Its real value is operational: support and QA stop guessing which build a customer is on, and deploy verification becomes visual instead of a Slack thread. Cost is effectively one engineer-hour; there is no infrastructure, licensing or vendor commitment. The trade-off is maintenance risk on an unproven open-source component — mitigated by pinning the version and treating the code as forkable in-house at trivial cost.
For engineering: One composer require, one plugin registration on the panel. It resolves the version through a priority chain (config → env → Composer → git), inherits panel colours, and hides from unauthenticated users by default. No runtime service dependencies, no migrations, no config publishing required to get value. It is small enough to audit in a single sitting and small enough to own outright if upstream goes quiet — so the decision is low-regret either way. Pair it with proper release tagging in your error tracker; the chip is a convenience layer, not the source of truth.