Foundation Emails Bundle Laravel Package

Product Decisions This Supports

• Email as a first-class product surface (Symfony stacks). If your team already builds UI with Zurb Foundation and wants design parity between web and transactional email, this bundle lets engineers author emails in Inky/Foundation syntax inside the existing Symfony templating and mailer flow instead of maintaining a parallel hand-coded HTML email codebase.
• Build vs. buy for email templating. This package represents the "assemble from open source" path versus (a) buying a hosted template platform (SendGrid/Postmark/Litmus-style tools), (b) adopting MJML as a build-step toolchain, or (c) hand-rolling responsive email HTML. It is a viable prototype-tier input to that decision, not a platform commitment.
• Roadmap scoping for lifecycle/transactional messaging. Useful as a spike to validate how much engineering effort responsive-email rendering actually costs in your stack before you commit headcount or a vendor contract to a broader email design system.
• Feature decisions around template ownership. If PMs want marketing/design to own email templates without engineering releases, the relevant question is whether a compiled-template bundle like this fits, or whether you need a hosted editor with preview/approval workflows. This package only supports the former (developer-authored templates in the repo).
• Important framing correction: despite the "Laravel/PHP" prompt, this is a Symfony bundle, not a Laravel package. For a Laravel product this is a non-starter for direct adoption and only informs the decision category, not the implementation.

When to Consider This Package

Consider it only when all of these hold:

• Your application is Symfony (not Laravel, not framework-agnostic PHP).
• Your design system is already Foundation for Emails / Inky, so the bundle removes real duplication rather than adding a new dependency.
• You are comfortable vendoring or forking: 0 stars, 0 dependents, and a single-maintainer profile mean you should assume you own the maintenance burden. Budget for pinning a commit and reading the source before relying on it.
• The scope is internal or low-stakes transactional email where a rendering bug is embarrassing but not revenue-critical, and you can iterate quickly.
• You have legal sign-off on AGPL-3.0. This is the gating item, not a footnote — see below.

Look elsewhere when:

• AGPL-3.0 is incompatible with your distribution model. For a commercial or SaaS product, AGPL's copyleft and network-use obligations can force source disclosure of the combined work. Most organizations will reject this outright for core product code. This alone likely disqualifies the package for anything customer-facing and proprietary.
• You need vendor support, SLAs, security patching, or a maintained release cadence. Zero adoption means zero community bug-finding on your behalf.
• You are on Laravel — evaluate MJML-based tooling, Laravel mail Markdown components, or a hosted template service instead.
• Your email program is revenue-critical (onboarding, receipts, password resets at scale) — you want a toolchain with previews, client-compatibility testing, and a real maintainer.
• You want non-engineers authoring templates — this is a developer-in-repo workflow, not a marketing tool.
• A build-pipeline alternative (MJML or the Foundation for Emails CLI compiled in CI) gets you the same output with no runtime dependency and no license entanglement.

How to Pitch It (Stakeholders)

To executives: This is a small, unproven open-source Symfony add-on for compiling responsive email templates. It is not a platform bet. Two facts dominate the recommendation: it has essentially no adoption (0 stars, 0 dependent projects), and it is licensed AGPL-3.0, which creates real legal exposure for a proprietary or SaaS product. My recommendation is do not adopt it in the product; at most, run a short time-boxed spike to learn what responsive-email templating costs us, then choose between a build-pipeline approach (MJML/Foundation CLI in CI) or a hosted template vendor.

To engineering: If your stack is Symfony and you already use Foundation for Emails, this saves you the Inky-compilation plumbing — but you are effectively adopting an unmaintained dependency. Pin it, read the source, and be prepared to fork. If you are on Laravel, this does not apply; use MJML or Laravel's native mail components.

To legal/security: Flag AGPL-3.0 for review before any code is merged. Assume no upstream security response; we own patching if we ship it.

Decision requested: Approve a ≤1 week spike (no production dependency) to benchmark this against MJML, and confirm whether AGPL-licensed code is permitted anywhere in our dependency graph. Default answer if legal says no: build the pipeline, skip the bundle.