Filament Blog Laravel Package

Product Decisions This Supports

• Build vs. buy on commodity CRUD. Blog post/category management is solved, undifferentiated work. Adopting this strips roughly 2–4 weeks of scaffolding (Filament resources, forms, tables, policies, media handling) out of the roadmap and redirects it to differentiated product work.
• Content marketing launch without derailing the core roadmap. Gives marketing a self-serve back office, so engineering stops being a ticket queue for copy changes. This is usually the real unlock — publishing velocity, not the code itself.
• Faceless architecture as a deliberate fit. The package intentionally does not own routes or views. Adopting it does not force a rendering decision: it drops behind Blade, Next.js, Nuxt, or anything else. That keeps the frontend decision on its own merits and reversible.
• Editor strategy made explicit. Configurable richtext vs. markdown lets us match tooling to writer cohort — marketers get WYSIWYG, engineers/docs get markdown — and keeps content portable if we migrate later.
• Scope definition for the public site. Because it's admin-only, it cleanly separates "content management" from "content delivery." SEO metadata, sitemaps, scheduling, revisions, and i18n become a named follow-on backlog rather than a launch-week surprise.
• Lock-in posture. MIT, data lives in our own database, forkable. Low switching cost relative to a SaaS CMS contract.
• Stack-currency signal (new in 5.0.0). The maintainer shipped first-party support for Filament 5 / Laravel 13. That is evidence of a live compatibility track record, which materially de-risks one of the two flagged adoption risks (framework coupling) — while leaving the other (bus factor) unchanged.

When to Consider This Package

Adopt when:

• Filament is already (or is about to be) our admin layer — the plugin is near-free incremental value on top of a stack decision we've already made.
• Our Filament major matches a supported release line: pin 5.x on Filament 5 / Laravel 13, pin 4.x on Filament 4. Do not assume a 5.x install drops into a Filament 4 app — this is a hard major-version pairing, not a soft one.
• We have 1–5 internal authors, one blog, and no complex editorial workflow (no multi-stage approvals, no per-locale content trees).
• The shipped content model — posts plus categories — covers ~80% of what we need out of the box.
• Timeline pressure is real: we need a publishing surface in days, not a quarter.
• We're willing to own a small fork. With ~200 stars, zero dependents, and a single maintainer, we are effectively the maintainer of last resort. That is a deliberate, acceptable trade only if we price it in — and 5.0.0 is exactly the event that prices it: a major bump means our fork must be rebased, not just fast-forwarded.

Look elsewhere when:

• We're not on Filament — adopting Filament solely for a blog is a bigger architectural commitment than the blog itself.
• We're locked to an older Filament/Laravel major for other reasons. The 5.0.0 line moves with the framework; if our platform lags, we end up maintaining a fork against a release line the maintainer has already moved past.
• We need genuine editorial workflow: review/approval stages, scheduled publishing, revisions, multi-language, granular per-role permissions.
• Content modeling goes beyond a blog (landing pages, docs, product content) → headless CMS (Sanity, Contentful, Strapi) or purpose-built Filament resources.
• We need vendor SLAs, enterprise support, or a hardened authoring surface for a high-traffic public property.
• Filament major-version incompatibility with our stack makes the fork cost exceed the build cost. Note this is now a lower probability risk than before 5.0.0 — the maintainer has demonstrated willingness to track framework majors — but a higher magnitude one if we adopt on a lagging platform, since we'd be diverging from active development.

Recommended gate before commitment: a 1–2 day engineering spike to (a) confirm whether we target the 5.x or 4.x release line based on our actual Filament/Laravel versions, (b) verify upgrade mechanics from whatever version we prototype on, (c) model the migration, and (d) size the custom work (SEO fields, scheduling, roles). Approve on the spike's output, not the README.

Release-specific note (5.0.0): Treat this as a breaking change for any existing fork or spike branch. The changelog is narrow — framework compatibility plus a CI dependency bump — so there is no new feature surface to re-evaluate; the decision-relevant delta is supported-version alignment and maintenance momentum. If we had already prototyped on 4.x, rebase before re-running the spike rather than assuming a drop-in.

How to Pitch It (Stakeholders)

For executives: A free, MIT-licensed admin plugin that gives marketing a self-serve blog back office in days instead of weeks — no SaaS subscription, no content leaving our database, no new vendor relationship. Because it's "faceless" by design, it doesn't lock us into a frontend stack; the public site ships whenever and however the web team wants. The latest major release adds support for the current generation of the underlying framework, which is a good sign the project is being actively tracked rather than abandoned — but it also confirms the dependency moves in lockstep with that framework, so our upgrade cadence becomes partly coupled to it. The honest caveat remains maintenance risk from a small open-source project, mitigated by forking it and carrying a modest internal ownership cost. Net: content marketing capability this cycle, at roughly the cost of a compatibility spike.

For engineering: It's a Filament plugin, not a framework — it ships resources, forms, tables, and policies for posts and categories, and deliberately leaves public routing to us. Installation is additive and doesn't touch application architecture. Release 5.0.0 pins the package to Filament 5 / Laravel 13; 4.x remains the line for Filament 4. So the first decision isn't "adopt or not," it's "which release line does our platform support" — get that wrong and the fork cost balloons. The real risks are tight coupling to Filament's major version and a single maintainer; 5.0.0 reduces the first only in the sense that it proves the maintainer will do the work, not that it will always be timely relative to our own upgrade schedule. Keep the mental model: a starting point we own, not a dependency we outsource. Budget the spike for line selection, compatibility, and an allowance for SEO fields, scheduling, and role extensions.

For marketing: You get a real back office with an editor that matches how you write, plus a clear list of what's phase two (SEO fields, scheduling). Set expectations that the public-facing blog is a separate, parallel build — the plugin manages content, it doesn't render it. The new release is plumbing rather than features: nothing changes about what you can do day to day, it just keeps the tool current with the platform underneath it.