Hermes Bundle Laravel Package

Product Decisions This Supports

Feature decisions

• Transactional email admin UX: Hermes gives a ready-made back-office for composing, previewing, scheduling, and auditing templated emails. That supports a roadmap item like "marketing/product can edit lifecycle emails without engineering tickets" — a common ask in B2B SaaS and internal-tool roadmaps.
• Lifecycle & campaign emailing without an ESP: If the roadmap includes welcome sequences, digests, or segmented announcements but the volume doesn't justify Braze/SendGrid/HubSpot, this is a credible "good enough" layer over Symfony Mailer.
• Recipient-level observability: Per-recipient status, error messages, resend, and cancel-send support support-ops features ("resend the invoice email to this customer") that would otherwise be manual SQL or a ticket to engineering. As of 1.14.5 the mail-level status rollup also accounts for CC recipients, so the sent/failed badge reflects the whole envelope rather than the To-list alone — a small but real correction for teams that CC stakeholders on customer-facing mail.
• Compliance-adjacent features: Unsubscribe links (with URL fix), translatable emails, CC sublists, attachments, and draft editing map directly to GDPR/CAN-SPAM-adjacent requirements and multi-locale products. Buying/borrowing this is far cheaper than specifying it from scratch.

Build vs buy vs borrow

• Borrow beats build if the team is already on Symfony + CruditBundle: this is a thin, MIT-licensed wrapper that removes weeks of CRUD-and-mailer glue.
• This is not a Laravel package. Despite being PHP/Composer, it is a Symfony Bundle that assumes Symfony's DI container, Twig, and CruditBundle's admin abstractions. In a Laravel codebase it is best treated as a reference implementation (schema for mails/recipients/status, unsubscribe-token flow, MJML pipeline) rather than a dependency.
• Buy beats borrow for anything with deliverability SLAs, volume scaling, sequencing, A/B testing, or analytics — that's an ESP conversation, not a bundle decision.

Roadmap / risk decisions this surfaces

• The release train has kept moving since the last review — 1.11.x at assessment time, now 1.14.5 — with small, frequent, single-purpose PRs. That is a stronger maintenance signal than a single release.
• 1.14.5 is a patch-level fix plus a new partial, not a feature or a break. No migration, deprecation, or API change is implied. It does not change the adoption calculus; it only trims risk slightly.
• 2 stars and 0 dependents still means effectively single-vendor code. Any adoption decision must include an explicit owner and a fork-maintenance line item on the roadmap. The upside: MIT license makes forking and internal ownership legally trivial.
• The changelog itself is evidence of coupling: the 1.14.5 entry references a crudit issue (crudit#668) and ships a partial template alongside the fix. Bug-for-bug, the bundle moves in lockstep with CruditBundle — reinforce the version-pinning discipline.

When to Consider This Package

Adopt when

• Stack is Symfony with CruditBundle (or you're willing to add CruditBundle). Outside that combination, integration cost dominates the value.
• You need template-managed, admin-editable email — multilingual, with attachments, CC/BCC, drafts, unsubscribe, cancel/resend — and don't need sequencing or analytics.
• You want an internal, low-volume or ops-driven mail tool where Symfony Mailer's transports are sufficient.
• You have a named maintainer comfortable in Symfony Bundle wiring who can own a fork if upstream stalls.

Look elsewhere when

• You are Laravel-first. Use illuminate/mail, Blade/Markdown mailables, and Notifications; port Hermes' ideas (recipient status model, unsubscribe token, draft/cancel states) rather than the code.
• You need deliverability guarantees, high volume, or multi-channel (SMS/push) — pick an ESP plus a notification abstraction.
• You need marketing automation: journeys, segmentation, A/B tests, send-time optimization.
• Procurement or SOC2-style vendor review applies: 2 stars / 0 dependents / no external adopter base will not clear a supply-chain review. Mitigate with a vendored fork and pinned version.
• You require Laravel queues, Horizon, or event-driven send pipelines natively — bridging Symfony Mailer into Laravel queues is real work with limited payoff.

Minimum due-diligence checklist before committing

1. Confirm the Symfony + CruditBundle version pairing (releases reference Crudit 1.17.4 and Symfony 8 compatibility — verify against your pinned versions, and note that fixes now land in response to Crudit issue numbers, so the two move together).
2. Read docs/ end-to-end; confirm config surface (CKEditor, MJML, transports) matches your environment.
3. Fork and pin; add CI (they ship PHPStan + PHPUnit badges — mirror them).
4. Prototype the unsubscribe link and translation flow — historically the buggiest areas per the changelogs.
5. Define what "sent" means for your ops team. 1.14.5 taught the status rollup about CC recipients; confirm BCC and multi-recipient semantics match the support runbook before you expose the badge to non-engineers.

How to Pitch It (Stakeholders)

For executives

"Hermes is a small, MIT-licensed component that gives us an admin screen for managing and sending templated emails — multilingual, with attachments, unsubscribe handling, and per-recipient delivery status. It could take roughly 3–6 engineering weeks out of an email-admin roadmap item, with no license cost and no vendor lock-in. The project is still shipping steady, low-risk patch releases, which is a modest positive. Two caveats unchanged: it only fits our Symfony-based admin stack, not our Laravel services, and it's a low-adoption open-source project, so we'd own a pinned fork. Recommendation: adopt in the Symfony admin surface where it fits, and treat it as a design reference for the Laravel side."

For engineering

"It's a thin Symfony Mailer wrapper with CruditBundle CRUD on top: Mail and Recipient entities, Twig templates (CKEditor + MJML configurable), status filtering, drafts, cancel-send, resend-per-recipient, CC sublists, attachments, and unsubscribe tokens. Value is the domain model and admin glue, not novel mail logic. Latest release 1.14.5 is a patch — mail status now counts CC recipients, plus a new partial; nothing breaking. Cost remains Symfony DI + Twig + Crudit coupling and a small, single-vendor maintainer base — so we vendor it, pin it, keep our own PHPStan/PHPUnit gates, and don't build anything on undocumented internals. On Laravel, we don't install it; we copy the recipient-status and unsubscribe patterns into our existing mailables, and copy the corrected status semantics too — a failed CC should flip the envelope to failed."

Framing the ask

• Approve as a time-boxed pilot on one Symfony admin surface, not a platform standard.
• Success criteria: template edits shipped without engineering, delivery status visible per recipient and correct across CC/BCC, unsubscribe compliant, no fork divergence from upstream for one quarter.
• Kill criteria: upstream inactive for two release cycles, or config surface conflicts with our Symfony/Crudit pin.