Hermes Bundle Laravel Package

Product Decisions This Supports

• Feature Expansion:

  • Enables templated email workflows (e.g., user notifications, transactional emails) with zero custom development for core email logic. Reduces time-to-market for features like:
    • Password reset flows.
    • Order confirmations/receipts.
    • Multi-language email support (via translatable templates).
  • Admin-driven email campaigns (e.g., newsletters, bulk alerts) via CruditBundle’s UI, eliminating the need for custom admin panels.

• Roadmap Alignment:

  • Accelerates MVP delivery for projects requiring email functionality tied to a Symfony/Crudit-based admin panel (e.g., SaaS platforms, CMS-driven sites).
  • Future-proofs email infrastructure by leveraging Symfony Mailer’s ecosystem (e.g., compatibility with Symfony 8+ and Laravel via bridges).
  • Modular design allows incremental adoption (start with templates, later add dashboards or queues).

• Build vs. Buy:

  • Avoids reinventing email logic when Symfony Mailer’s capabilities (SMTP, transports, events) are sufficient but require templating/management layers.
  • Lower total cost of ownership (TCO) compared to building a custom solution or licensing a full-fledged email service (e.g., Postmark, Mailchimp).
  • Reduces technical debt by using a maintained (albeit niche) package with active development (releases every 1–2 months).

• Use Cases:

  • Transactional Emails: Automated, one-off emails (e.g., "Your account was created").
  • Marketing Emails: Newsletters or campaigns managed via CruditBundle’s UI (e.g., drag-and-drop templates).
  • User Communications: Welcome series, alerts, or digests with personalized content (e.g., {user.name} placeholders).
  • Legacy Modernization: Replacing hardcoded emails in legacy Symfony apps with templated, maintainable workflows.
  • Multi-Language Support: Translatable email templates for global audiences (e.g., en.yml, fr.yml).

When to Consider This Package

• Adopt if:

  • Your project uses Symfony Mailer or can integrate it via spatie/laravel-symfony-mailer (e.g., Laravel + Symfony hybrid stack).
  • You need template-based emails with minimal boilerplate (Twig/Blade templates) and admin panel management (CruditBundle).
  • Your team prioritizes developer velocity over custom email service features (e.g., no need for advanced analytics, A/B testing, or deliverability tools).
  • You’re building a Symfony/Crudit-driven admin panel and want to consolidate email logic in one place.
  • Your use case fits transactional or low-volume marketing emails (not high-throughput campaigns requiring dedicated services).

• Look elsewhere if:

  • You require scalable transactional email volume (e.g., 10K+ emails/hour) → Use SendGrid/Mailgun or Laravel’s native illuminate/mail with queues.
  • Your project does not use CruditBundle and needs standalone email management → Evaluate:
    • Laravel Notifications (for multi-channel support).
    • Symfony Mailer directly (if no templating/UI needs).
    • Mailchimp API (for marketing-focused campaigns).
  • You need multi-channel notifications (SMS, push, in-app) → Use Laravel Notifications or Twilio/Segment.
  • Your team requires advanced email features like:
    • A/B testing → Use Mailchimp/Klaviyo.
    • Deliverability analytics → Use Postmark/Mailgun.
    • Complex workflows (e.g., email sequences) → Use Customer.io or Breezy HR.
  • You’re all-in on Laravel and want to avoid Symfony dependencies → Use Laravel’s built-in Mailer or spatie/laravel-activitylog for notifications.

How to Pitch It (Stakeholders)

For Executives/Business Stakeholders: *"HermesBundle lets us ship email-driven features faster by combining the reliability of Symfony Mailer with the flexibility of templated emails—all managed through our existing CruditBundle admin panel. This avoids the cost and complexity of building a custom solution or licensing a full email service for simple use cases like user onboarding or order confirmations.

• Saves 30–50% dev time on email logic by reusing templating and admin tools.
• Low risk: MIT-licensed, actively maintained, and integrates with our Symfony stack.
• Scalable: Starts with basic emails but can grow with features like queues or dashboards. Best for: Transactional emails, newsletters, or alerts where templating and admin control matter more than advanced analytics."*

For Engineering/Technical Stakeholders: *"HermesBundle gives us a pre-built email system that:

1. Wraps Symfony Mailer with CruditBundle integration for admin-panel email management (no custom UI work).
2. Supports Twig templates (easy to extend with Blade or MJML for responsive emails).
3. Reduces boilerplate for common tasks (attachments, CC/BCC, unsubscribes, drafts). Tradeoffs:

• Not Laravel-native: Requires spatie/laravel-symfony-mailer and some DI work.
• Crudit dependency: Can be forked to remove if needed.
• Limited to basic emails: For advanced use cases, we’d pair it with a dedicated service. Recommendation: Use for MVP email features, then evaluate migration to Laravel Notifications or a dedicated service if needs grow."*

For Product Managers: *"This package aligns with our roadmap for user communications (e.g., onboarding, alerts) by:

• Enabling templated emails without blocking the team on HTML/CSS.
• Centralizing email management in CruditBundle (reducing tool sprawl).
• Future-proofing for multi-language support or campaign tracking. Key questions to validate:

1. Does our admin panel need CruditBundle, or can we replace it?
2. Are we okay with Symfony Mailer as a dependency, or should we use Laravel’s native Mailer?
3. What’s the long-term plan if HermesBundle stagnates?"*