Feedamic Laravel Package

Product Decisions This Supports

• Feature: ship syndication as a checkbox, not a project. RSS/Atom is table stakes for blog, news, changelog, documentation, and podcast surfaces. This package turns "we should have feeds" from a sprint item into a config file plus an Antlers template, which is the correct amount of investment for a commodity capability.
• Build vs. buy, decided cheaply. Rolling your own feed means owning XML escaping, RFC 822 vs. RFC 3339 date formats, stable GUIDs, CDATA vs. escaped content, Atom self/alternate links, and enclosure MIME/length correctness. That is 1–3 days of work plus indefinite maintenance for zero differentiation. Buying wins unless feeds are your product.
• Roadmap: deprioritize a feeds epic. Any pending "add RSS" story can be closed as an addon adoption rather than scheduled engineering work — freeing the roadmap for features that actually differentiate.
• Per-surface feeds without per-surface code. Typical use cases to scope: one feed per collection, feeds filtered by taxonomy or author, a podcast feed with enclosures, a multi-site feed, and <link rel="alternate"> autodiscovery in the layout head. Each is a configuration/templating exercise rather than new application logic — a meaningful reduction in scope for a multi-site or multi-audience content platform.
• Distribution channel decisions. Feeds feed aggregators, newsletter tooling, Zapier/IFTTT automations, and partner syndication. Whether to expose full content or excerpts in the feed is a real product decision (SEO, paywall, ad impressions) — and one this package lets you make in a template rather than in PHP.
• Platform evaluation input. If you are weighing Statamic against WordPress, native-ish feed support narrows the gap; if you are weighing Statamic against a hand-rolled Laravel CMS, this removes an argument for the latter.
• Customization posture. Because output is templated rather than hard-coded, content/marketing can iterate on feed contents (summary length, included fields, image handling) without an engineering ticket — a workflow decision as much as a technical one.

When to Consider This Package

Adopt when most of the following are true:

• You are already on Statamic (confirm the supported major version in the addon's composer.json against your install — the release cadence suggests active maintenance, but verify the constraint before committing).
• You need standard RSS 2.0 and/or Atom for one or more collections, optionally scoped by taxonomy, author, or site.
• You want feed output configurable without touching PHP — the templating approach is the main reason to pick this over a generic Laravel feed library.
• Your team has no appetite to own XML serialization, and the cost of being wrong is low (feeds are re-generatable and cacheable; a malformed feed is an inconvenience, not an outage).
• Feed volume is modest and cacheable — this is a content-site capability, not a high-QPS feed API.

Look elsewhere, or build, when:

• You are not on Statamic. Use spatie/laravel-feed or a hand-rolled response; adopting a CMS-specific addon for an unrelated stack is a non-starter.
• You need podcast-specific depth — Podcasting 2.0 namespaces, transcripts, chapters, funding tags, dynamic ad insertion. Verify enclosure support carefully; treat podcasting as its own evaluation, not a checkbox.
• You need per-user, authenticated, or personalized feeds. That is application logic; a static-ish feed generator will fight you.
• Syndication is revenue-critical (news distribution, licensing, partner integrations). Signal quality here is thin — a low star count, zero dependents, and a small-agency maintainer mean a bus factor of roughly one. For a revenue-bearing surface, either vendor the source and assign an internal owner, or budget a fork.
• You need JSON Feed, WebSub/ping, ETag/Last-Modified conditional GET, or edge caching with purge hooks. Check these explicitly; if they are missing and you need them, the "buy" saving evaporates.
• You require SLA-backed support or a security review cadence. A solo-maintainer addon cannot provide either.

How to Pitch It (Stakeholders)

To executives: Our content platform is missing a baseline distribution feature — syndication feeds. Audiences, aggregators, and automation tools consume content via RSS/Atom, and today we either can't serve them or would spend engineering days building it. A small, purpose-built addon closes the gap for roughly the cost of a config change and a template, with no new infrastructure and no new service to operate. It converts a recurring "when will we have feeds?" question into a one-time, low-risk decision.

To engineering: This is a thin Statamic addon that generates RSS and Atom output from collections, with the feed body defined in Antlers rather than in PHP — so content changes to the feed don't need deploys of application code. It sits on the existing Laravel HTTP layer, adds no runtime dependencies, and needs no queue or cron. The trade-off is explicit: the package is small and effectively single-maintainer with no downstream dependents. Mitigation is cheap — pin an exact version, keep the feed definitions in version control, and note that a replacement (or a fork) is a day of work rather than a quarter's. Recommendation: adopt for standard collection and taxonomy feeds now; treat podcast-grade output and any revenue-critical syndication as a separate, deliberate evaluation rather than assuming this covers it.