Filament White Label Laravel Package

Product Decisions This Supports

• Build vs. buy for panel theming. White-labeling a Filament admin panel is a recurring, deceptively expensive build: brand assets, favicon plumbing, color tokens across light/dark, font loading, layout tweaks, footer copy, and custom CSS injection, plus the guardrails so a bad hex value or missing logo doesn't take down the panel. This package collapses that into a settings surface, so the decision becomes "do we own a theming subsystem or do we consume a plugin" rather than "how many sprints does the theme work cost."
• Multi-tenant branding as a sellable feature. Because storage is per-panel with optional per-tenant rows, this is the enabler for tiering: single-brand deployments at the base tier, tenant-specific branding (logo, colors, footer, fonts) at an enterprise/agency tier. That's a pricing-page decision, not just an engineering one.
• Roadmap sequencing for white-label and reseller motions. If reseller/OEM deals are on the roadmap, this determines how early "each customer sees their own brand" can ship. The per-tenant row model means brand configuration is data, not a deploy — which is what makes an agency or reseller channel operationally viable at all.
• Onboarding and demo strategy. Brand name, logo, and color changes are editable at runtime, so sales can stand up a branded demo tenant in minutes instead of a forked environment. That affects whether demos are a product-managed workflow or an engineering request queue.
• Scope discipline on theming requests. A named list of supported surfaces (brand, six color roles, fonts, layout, footer, sanitized CSS) gives you a defensible "in scope / out of scope" line. Custom per-customer layout surgery stops being a default yes.
• Risk acceptance around dependency weight. Filament v5 is the hard requirement; adding a third-party theming layer to the panel shell is an architectural bet with a low-traffic maintainer. That's a decision to make explicitly with engineering, not to discover in production.

When to Consider This Package

Adopt when most of the following hold:

• You are on Filament v5 and the admin panel is the customer-facing surface — i.e., branding is a product feature, not cosmetics for internal staff.
• You have multiple panels or tenants and the alternative is hand-rolling a settings table, a Filament plugin, and a theme-resolution layer yourself.
• You need runtime-editable branding (no deploy to change a customer's logo or primary color), which is the real differentiator versus a static custom theme.
• Your branding requirements fit the supported set: brand name, light/dark logos, favicon, logo height, six color roles, Bunny Fonts, layout, footer, sanitized CSS.
• You are comfortable vendoring a small, young MIT package — or forking it. With 13 stars, zero dependents, and a v1.0.0 release, treat it as a well-scoped starting point you can own if the maintainer goes quiet, not as a hardened dependency.
• You can absorb Bunny Fonts as the font delivery mechanism; if your org mandates self-hosted or licensed typefaces, budget for extension work.

Look elsewhere or build in-house when:

• You are not on Filament v5, or you're on a Filament version that will diverge — the package is version-locked to a framework major.
• You need branding beyond the panel shell: transactional emails, public marketing pages, PDFs, and API-rendered output all need their own theming story. This package does not unify them.
• You need fine-grained design-system control — component-level overrides, dense layout variants, per-tenant component composition. Sanitized CSS is a pressure valve, not a design system.
• Compliance or enterprise procurement requires a vendor with SLAs, security review, or a maintained release cadence you can point at in a contract. Zero dependents and a single maintainer will not clear that bar.
• Your tenant count is one and branding changes ship quarterly — a static custom theme is cheaper than a new dependency.
• Font licensing or CSP constraints make the external font source a blocker rather than a config detail.

How to Pitch It (Stakeholders)

To executives: White-labeling is a revenue feature — it unlocks agency, reseller, and enterprise tiers where customers expect to see their own brand, not ours. Today that capability is either absent or a bespoke engineering project every time a deal requires it. This package makes brand identity a per-tenant setting instead of a code change, which means the cost of serving a branded customer drops from a sprint to a form submission, and the branding tier becomes something we can price and sell. It's MIT-licensed and small enough to fork if we ever need to, so we are buying speed, not lock-in.

To engineering: It's a Filament v5 plugin that owns the theming surface end to end — brand assets, favicon, six color roles with light/dark handling, fonts, layout, footer, and sanitized custom CSS — persisted per panel with optional per-tenant rows, plus guards so a broken logo path or malformed color doesn't take the panel down. That's the plumbing we would otherwise write and maintain ourselves, and the safety guardrails are the part that's easy to get wrong. Caveats worth naming up front: v1.0.0 with ~13 stars and no dependents, single maintainer, hard dependency on Filament v5, and Bunny Fonts as the font pipeline. Recommendation is to adopt behind our own abstraction or fork-and-vendor it — pin the version, own the fork if needed, and keep the theming interface ours so we're never blocked on upstream.

To sales and customer success: Branded demo and onboarding environments become self-service. Logo, colors, and footer copy are runtime settings per tenant, so a prospect or new account can see their own brand without filing an engineering ticket or waiting on a deploy.