Aurum Filament Theme Laravel Package

Product Decisions This Supports

• Time-to-demo for internal admin tools. If the roadmap includes shipping an admin/back-office panel (ERP, CRM, ops console, finance dashboard) on Filament v5, this package compresses the "make it look credible in front of executives" phase from days of Tailwind/CSS work into a few lines of PanelProvider config. That is a schedule lever for a demo or pilot, not a product differentiator.
• White-label / per-tenant branding decisions. The AurumPreset abstraction (Gold, Emerald, Sapphire, Ruby) plus custom presets means the "do we build a theming layer or buy/borrow one?" question has a cheap answer: extend AurumPreset with your brand palette instead of building a design-system package. This directly supports decisions about whether multi-tenant panels get distinct visual identities, or whether one neutral brand ships to all.
• Build vs. buy on the design layer. The realistic comparison is not "this package vs. nothing" — it's "this package vs. 1–2 sprints of a frontend engineer reimplementing Filament's theming hooks." The zero-build install (CSS registered by the plugin, no Vite step in the consuming app) and panel-scoped registration are the genuinely load-bearing technical claims, because they mean the theme can be adopted and dropped without touching the app's asset pipeline.
• Scope discipline for finance/ops-facing surfaces. The opinionated components — AurumStatsOverview/AurumStat with trend indicators, AurumValueList, Timeline, TotalsBlock with tabular mono numerals, and accentRgba() for theme-aware charts — map directly onto the recurring "KPI cards, order timeline, order totals" pattern in commerce and ERP admin. Using these instead of bespoke Blade widgets removes a class of one-off UI code from the roadmap.
• Accessibility as a gate, not an afterthought. WCAG contrast gates are asserted in the test suite rather than left to visual review. That turns "is the panel accessible enough for an enterprise procurement review?" into a checkable item, which matters for public-sector or large-enterprise sales cycles.
• What it does not decide. This is presentation only. It has no bearing on data model, API surface, tenancy model, authorization, or performance. Treat it as a CSS/UX dependency with an unusually low blast radius, not an architectural choice, and do not let it into a roadmap discussion as though it were strategic.

When to Consider This Package

Consider it when all of the following hold:

• You are on FilamentPHP v5 specifically (filament/filament ^5.0) and PHP ^8.2. Filament's theming APIs churn between majors; there is no reason to expect a v4 story here.
• The panel is customer- or executive-facing enough that "default Filament look" is a liability — sales demos, investor updates, or a product where the admin surface is part of the value proposition.
• You want zero build step in the consuming app. If your team already owns a Tailwind/Vite pipeline and a design system, the value drops sharply.
• You want the opinionated look (dark sidebar in light mode, gold-on-graphite, Instrument Sans + IBM Plex Mono). This is a strong aesthetic bet. If it clashes with your brand, adopting it means fighting it.
• You can accept near-zero community validation. Ten stars, one author, zero dependents, maturity limited to README + changelog. This is the dominant risk and it is a maintenance risk, not a correctness risk.

Look elsewhere when:

• You are not on Filament — this is not portable to Livewire/Blade/Inertia stacks.
• You need multi-brand theming at runtime per tenant with more than a preset swap. Custom presets are PHP classes resolved at panel boot; dynamic per-request theming is out of scope and you will be writing that yourself anyway.
• You need a maintained design system with a roadmap, SLA, or vendor support. There is none. Budget for the possibility that you fork it. MIT licensing makes forking the realistic fallback and should be the assumed plan, not the contingency.
• Bundle/asset governance is strict. "The plugin registers CSS into your panel" is elegant, but in an environment with CSPs, asset fingerprinting, or a mandated component library, that injection point needs review before it becomes a dependency.
• The app is already visually differentiated — you would be paying an adoption cost (and a novelty cost) for changes you would immediately override.

The practical verdict: adopt on a non-critical internal panel first, verify the visual result against your brand, and keep the fork option open. Do not adopt it on a revenue-critical customer-facing surface until it has survived at least one Filament minor-version bump in your own CI.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a theme for our admin panels — it makes the back office look like a product rather than an internal tool, at essentially no engineering cost. It is a small open-source package (MIT, free) that we configure in a few lines rather than building ourselves, which saves roughly one to two sprints of frontend work on any panel we ship. It is cosmetic: it touches nothing about data, security, or how the system works, so the downside if we drop it later is a few hours of cleanup and some visual rework. The one thing to flag is that it is maintained by a single author with a small user base — so the honest framing is "cheap, reversible cosmetic win," not "platform investment," and we should assume we may end up maintaining our own copy.

To engineering: Low-risk, low-ceremony dependency. Register via ->plugin(AurumTheme::make()) in the PanelProvider; colors, fonts, and CSS are panel-scoped, so panels that do not opt in are untouched, and there is no Vite/Tailwind build step in our app. Version pin it, run php artisan filament:assets as part of the deploy, and put it behind a standard upgrade check — the real integration risk is Filament v5 minor bumps changing theming hooks, not this package's internals. Fork it if the author goes quiet; the surface area is small enough that a fork is a day of work, not a project. Two concrete things to verify during evaluation: our brand palette expressed as an AurumPreset (OKLCH 50–950 plus accentHex()), and that our logo assets are trimmed and legible on dark, since the login brand block and sidebar are always dark by design. The presets pass WCAG contrast tests in the package's own suite, which pre-answers an accessibility question we would otherwise have to raise in procurement review.