Boredom Laravel Package

Product Decisions This Supports

• A maintenance-sprint line item, not a roadmap bet. Filament panels routinely render grey circles or broken images for users without profile photos — user tables, ticket assignee chips, comment threads, activity logs. This package turns that fix into a one-line avatar-provider swap instead of a design/engineering project. Frame it as admin polish: visible quality improvement on internal tooling, zero roadmap capacity consumed.
• Closing the third-party avatar egress question. Filament's common defaults (Gravatar, ui-avatars.com) mean every avatar render is an outbound request carrying a user identifier — frequently an email hash — to a vendor. A locally generated deterministic SVG eliminates that call. For an EU-facing or regulated org, "we stopped shipping user identifiers to an image CDN on every page load" is a defensible compliance-adjacent win at near-zero cost. This is the strongest business argument available for the package; lead with it if privacy review is in scope.
• A deliberate build-vs-buy precedent. The capability is genuinely small: deterministic SVG seeded from a name or email, wired into Filament's avatar-provider contract. The honest position is buy for speed now, expect to vendor the ~50 lines when the admin surface matters. Record that decision explicitly — with 8 stars, 0 dependents, and a single maintainer, the continuity math favours eventually owning the code, and you want the reasoning on file before the next thin dependency asks the same question.
• A test case for dependency policy. This is a small, low-blast-radius example of how the org treats single-maintainer packages with no SLA and no security-backport commitment. The useful precedent isn't "no" — it's "yes, behind a configuration seam, with an initials fallback, pinned to an exact version, in internal surfaces only." Write that policy down once and it stops being relitigated per package.
• Upgrade-tax accounting. The 3.0.0 release exists to track Filament 5 plus a Dependabot bump — no functional change. Even a decorative package converts every framework major into your migration. Price that into the standing question of how many thin UI dependencies the panels tolerate, and bundle this bump into the Filament major upgrade commit rather than letting it ride in as unrelated Composer drift.
• Explicitly not a differentiator. Nothing here is customer-facing value the business can claim. Keep it out of release narratives, pricing conversations, and strategy decks.
• One diligence flag before any commitment. The repository carries two contradictory descriptions: an "avatar provider for FilamentPHP" and a "random activity suggester via the Bored API." The evidence — vendor is a Filament plugin shop, the 3.0.0 changelog's only substantive line is "support filament 5" — says the avatar reading is correct. Do not let an engineer start until that's confirmed against composer.json. Effort estimates and the entire privacy argument above hold only for the avatar reading.

When to Consider This Package

Adopt when:

• You run one or more Filament panels and users routinely appear without avatars — admin user tables, activity feeds, assignee chips, comment headers.
• You want to stop calling an external avatar host, and eliminating those requests, the cache-busting, and the accompanying privacy questions is worth a small dependency.
• The surface is internal or low blast radius — admin, back office, internal tools. A broken avatar is a cosmetic defect, not an incident.
• You want the change to be configuration, not code, and you'll keep an initials/silhouette fallback so the UI degrades cleanly if the package is ever removed.
• You can cap evaluation at half a day. If it takes longer, building the provider in-house has already won on cost.
• You will align Filament majors deliberately — bump this in the same commit as filament/filament, on a non-production panel first.

Look elsewhere — or vendor the ~50 lines — when:

• Brand, legal, or accessibility requirements apply. If design owns the avatar language (initials treatment, palette, contrast ratios) or accessibility owns the decorative-vs-labelled distinction, you are already past the point where a configurable off-the-shelf package pays for itself. Write the decision record before you start customising, so you're honest about whether you're buying or building.
• Avatars appear in customer-facing surfaces. Public profiles, customer portals, marketing pages — the package solves the cosmetic missing-avatar case and nothing else, and it isn't worth a user-visible dependency on a single-maintainer project. Internal only, or feature-flag it.
• Your stack doesn't match. If you're on Laravel 11 with Filament 3, verify 3.0.0 actually installs — a release whose only change is "support filament 5" often means the older line is unmaintained rather than supported. Check the require constraints before you schedule anything.
• You need an SLA, security backports, or a vendor to call. One maintainer, 8 stars, 0 dependents. You are the first person to hit any bug on Filament 5. That's acceptable for decoration; it is not acceptable for anything you'd have to page someone about.
• It would stop being a leaf dependency. The moment a Blade view, model, or migration references LaraZeus\Boredom\* directly, you've promoted a disposable package to foundation. Keep the only touchpoint the setAvatarProvider() call.

How to Pitch It (Stakeholders)

To executives: This is a small cleanup item for internal admin tooling, not a product investment. It replaces the grey placeholder avatars users see throughout our back-office panels with generated ones, and — more usefully — stops us sending user identifiers to a third-party image service on every page load. Cost is roughly half a day of engineering, capped; scope is internal panels only; removing it later is a one-line revert. It consumes no roadmap capacity and contributes nothing to customer-facing differentiation, so treat it as maintenance, not a launch item.

To engineering: A Filament avatar-provider swap. It's a thin, single-maintainer package (8 stars, 0 dependents) that generates deterministic SVGs locally, so there's no HTTP, no cache, no timeout, and no rate-limit configuration — which is precisely why it's safe to try. Install it, pin the exact version (3.0.*, not ^3.0), call Filament::setAvatarProvider() in the panel provider's boot(), and keep a small app-level wrapper class so the vendor namespace never leaks into views or models. Two things to verify before estimating: the repo's description contradicts itself (avatar provider vs. a Bored-API activity widget — the vendor's DNA and the changelog say avatar provider), and whether 3.0.0 installs cleanly on our current Laravel/Filament combination. Test that the panel renders without exception, not the SVG itself. And bundle the upgrade into the next Filament major bump rather than letting it float.

To design and compliance: Design gets a deterministic, generated avatar language we can tune within the package's config; if brand requirements go beyond palette and variant, that's the signal to build the ~50-line version ourselves. Compliance gets the concrete win: no outbound avatar requests, no email hashes leaving our infrastructure. Accessibility sits with us either way — the package won't ship aria-label handling for avatars rendered without adjacent text, so we wire that in at the resource level.

The one-line risk statement: Decorative dependency, internal surfaces, one maintainer, zero dependents — acceptable precisely because it stays decorative and stays at one configuration seam. The day it becomes a maintenance tax, composer remove plus one deleted line makes it disappear.