Filament Maillog Laravel Package

Product Decisions This Supports

• Build vs. buy for email observability: replaces the ad-hoc "email_log" table + admin CRUD a team would otherwise spend a sprint on. License cost is zero (MIT); the investment is integration and ongoing ownership.
• Support tooling roadmap: gives CS/ops a self-serve view of outbound mail, converting "the customer says they never got the invoice/reset/verification" from an engineering escalation into a lookup.
• Customer-facing trust features: enables "resend that email" and an email-history panel on the customer record — a small, high-perceived-value addition to account and billing screens.
• Audit and compliance posture: a queryable record of what was sent, to whom, and when. Useful evidence for billing disputes, subject access requests ("show me everything you emailed me"), and communication trails in SOC 2-style control narratives.
• Incident diagnosis: shortens the loop on delivery complaints without cross-referencing provider dashboards and application logs.
• Prioritization input: the volume of email-related support tickets is the honest signal for whether to adopt this now or defer. If tickets are near zero, this is a nice-to-have.
• Explicitly out of scope: marketing campaigns, deliverability tuning, open/click analytics. Those remain the ESP's job — this package records what your application sent, not what happened after.

When to Consider This Package

Consider it when:

• The stack is Laravel + Filament and the team already operates inside the admin panel — marginal UI cost is near zero.
• Transactional volume is modest, so DB-backed logging stays cheap and fast.
• No dedicated email observability budget exists, and provider dashboards are fragmented across one or more ESPs.
• You need something shippable in days, not a quarter, and the audience is internal.
• You can accept that full message bodies are stored and readable by admins, with role gating.

Look elsewhere when:

• You are not on Filament, or on a Filament major version without confirmed compatibility — integration cost then exceeds the value.
• Volume or retention requirements are large; unpartitioned, unpruned tables become both an operational and a PII liability.
• You need delivery events — bounces, complaints, opens, clicks. This logs the send, not the outcome; provider webhooks remain mandatory.
• Email bodies carry regulated data (PHI, PCI, sensitive PII). Redaction and retention controls are yours to build, and that changes the cost calculus.
• The product is multi-tenant and admins must never see another tenant's mail — verify scoping and authorization before rollout, not after.
• Maturity risk applies throughout: ~30 stars, zero dependents, and a single small maintainer. Treat it as early-stage. Pin the version, budget an owner, and be prepared to vendor or fork rather than wait on upstream.

How to Pitch It (Stakeholders)

For executives: A free, MIT-licensed admin add-on that turns "did the customer actually receive that email?" from an engineering investigation into a support-agent lookup. The cost is hours of integration — no license, no new infrastructure, no vendor contract. The return is fewer escalations, faster ticket resolution, and a defensible record of outbound communications for disputes and access requests. It is a supporting internal tool, not a platform bet, and it is removable if it disappoints.

For engineering: It hooks Laravel's mail events and persists outgoing messages for browsing in Filament — low blast radius, no vendor lock-in. Three conditions for adoption: pin the version and assign a maintainer (the community is small and there are no dependents to share the burden), define a retention and purge policy before go-live rather than after the table grows, and gate the Filament resource behind authorization so message bodies are not broadly readable.