Podcast Categories Laravel Package

Product Decisions This Supports

• Build vs. buy for podcast taxonomy. Apple Podcasts maintains a fixed, hierarchical category list (roughly 19 top-level categories, each with subcategories). Hand-rolling it means an editor-maintained taxonomy, an enum in code, validation on publish, and a maintenance chore every time Apple revises the list. This package ships that list as a preloaded, selectable fieldtype — a textbook "buy" for a capability that is not a differentiator. The counter-question worth asking in the room: the durable asset is the list, not the code, so "vendor ~a day of engineering" is a legitimate competing option.

• Podcast feature scoping. If the roadmap question is "should we support podcast content on this site?", this addon lowers the cost of the content-modelling half of that decision to one Composer dependency plus a blueprint field. It does not deliver players, episode feeds, enclosure management, or hosting integration — it delivers correct, consistent category data, which is the piece podcast directories actually validate.

• RSS/directory compliance as a quality bar, not a QA step. Podcast feeds are machine-consumed by Apple, Spotify, and others. Free-text category fields drift — typos, outdated labels, non-canonical names — and silently break directory validation. A constrained selectable field makes valid output the default. This is a defect-prevention decision, not a feature decision.

• Platform-upgrade sequencing input. v2.0.0 is explicitly a Statamic 6 compatibility release. That gives a clean answer to "is this addon available on our target platform major?" — yes, if we are on Statamic 6. The flip side: roadmap commitments assuming continued Statamic 5 support now need a pin-and-track decision rather than a default. The addon belongs in the dependency inventory reviewed before each CMS major, not discovered mid-migration.

• Prioritisation signal for a launch-critical path. If the podcast feed is brand- or revenue-critical, the lack of an upgrade guide, test suite, or maintainer depth becomes a real schedule risk (silent blank categories in a live feed), which argues for a thin internal wrapper or vendoring. If the feed is a nice-to-have, the addon is fine as-is.

When to Consider This Package

Consider adoption when:

• You run — or are committed to migrating to — Statamic 6 and publish podcast content. v2.0.0 is aligned to the current platform major. Adopting on Statamic 6 while pinning the v1 line means shipping against an unsupported combination.
• You want Apple Podcasts category consistency without owning the list. The value proposition is precisely the maintenance you don't do: no manual taxonomy, no enum to update, no divergence between editors.
• You need categories inside the authoring flow, not just in a feed template. A blueprint field means editors pick from the canonical list and the renderer just outputs it. That is a content-modelling convenience, not a runtime dependency.
• The blast radius is acceptable. This is a small, single-purpose addon (1 star, 0 dependents, one-line changelog). It should sit behind the content model, be trivially swappable for a hand-written select, and never be load-bearing for anything revenue-critical without a wrapper.

Look elsewhere, or defer, when:

• You are pinned to Statamic 5 or earlier. A platform-gated major almost certainly narrows the require block. Confirm the support policy explicitly; if the platform upgrade is not this cycle, stay on v1 and log it as an unmaintained branch on the risk register.
• You need more than categories. This package does not host episodes, generate feeds, manage enclosures, or integrate with podcast hosting. Scoping it internally as "podcast support" will disappoint stakeholders — scope it as "canonical category field."
• You want a different or multi-directory taxonomy. Spotify, YouTube, and others have their own schemes. If multi-directory publishing is on the roadmap, one Apple-shaped list may become one input among several rather than the source of truth.
• You require procurement-grade guarantees. There is no evidence here on security disclosure, test coverage, maintainer depth, or backwards-compatibility policy. Ask the maintainer; do not infer from a release note.
• A day of engineering to vendor the list is cheaper than ongoing dependency review. For a static, publicly documented taxonomy, this is a genuinely defensible alternative — and it makes the next CMS major a non-event.

How to Pitch It (Stakeholders)

To executives: This is a small, single-purpose addon that gives our podcast pages an Apple-curated category picker instead of an editor-maintained list. It removes an ongoing manual-maintenance chore, makes feed compliance the default rather than a QA checkpoint, and costs one dependency to adopt. Its latest release exists specifically to support Statamic 6, so it does not block our platform upgrade. The honest caveat is scale — one star, no downstream dependents, likely a single maintainer — which is acceptable for a non-differentiating convenience field and a clear reason to keep it swappable rather than foundational. The decision to fund is small; the decision it informs (do we support podcasts at all) is the bigger one.

To engineering: Treat it as a content-modelling dependency, not a platform. Install it, register the field in the podcast blueprint, and verify rendered values against Apple's current published category list. Because v2.0.0 is a compatibility release, the real work is the upgrade path: diff composer.json constraints for Statamic/Laravel/PHP between the installed v1 and v2, run composer why-not in a scratch branch to surface blocker addons before writing code, and validate against a staging clone of real content rather than a fresh install — fieldtype changes fail on legacy entry data, silently rendering blank categories into a live feed. Sequence strictly: platform major first, then this addon, then feature validation. If the field ever becomes launch-critical, wrap it behind our own category source so a stalled release cannot block a future CMS major — or vendor the taxonomy now and skip the dependency entirely.