Filament Blog Laravel Package

Product Decisions This Supports

• Make-vs-buy for a blog subsystem. This package is a bundle, not a screen: admin CRUD for posts/categories/authors plus public routes (/blogs), front-end views, comments, newsletter capture, subscriber notifications, SEO meta, and auto TOC. Buying it collapses an estimated 4–8 sprints of work (schema, Filament resources, public controllers, mail, comment moderation plumbing, rich-text rendering) into a config-and-migrate install. That is the core PM decision it informs: do we staff a blog, or do we spend a day integrating one?
• Roadmap sequencing. Because it unblocks a content-marketing/growth surface in days rather than a quarter, it lets you pull forward SEO/content experiments (launch blog → publish cadence → measure organic and email capture) without displacing committed product work. Conversely, if the blog is the product or a material revenue surface, this reprioritizes toward a bespoke build.
• Scope containment decisions. Scheduled publishing, SEO meta customization, author block, TOC, social sharing, reCAPTCHA-gated comments, and newsletter signup are all pre-built — so the PM conversation shifts from "what do we build" to "what do we enable." Each toggle is a product decision with downstream cost: comments mean a moderation and spam policy; newsletter signup means an email provider, consent language, and unsubscribe compliance; notifications mean owning deliverability.
• Audience and engagement strategy. canComment() on the User model is an explicit gating hook — a clean lever for member-only discussion, paid-tier community, or comments-off-entirely. That's a packaging/monetization decision the package lets you make without code changes.
• Content ownership and exit planning. Table prefixing (fblog_), configurable user model/foreign key/avatar columns, and HasBlog trait mean the blog can coexist with your users table rather than forking it. Low-friction adoption also means low-friction removal — supports a "reversible bet" framing.
• Version/pin strategy as a roadmap input. Major bumps track Filament majors (v3 → Filament 4, v4 → Filament 5) and v2 introduced a table-prefix migration requiring filament-blog:upgrade-tables. The PM decision is which major to pin and whether our Filament upgrade path is gated by this dependency.
• Not supported: content operations beyond a single blog (multi-channel syndication, content modeling/structured content, localization beyond the merged multi-language feature), editorial workflow approvals, or analytics/experimentation on content. If those are on the roadmap, they're incremental build regardless.

When to Consider This Package

Adopt when most of these are true:

• You are already on Filament 3.x / Laravel 11 (or on the matching newer major — v4 for Filament 5) with a panel provider you can register Blog::make() into. Fit is the whole value proposition; retrofitting Filament for this is a different project.
• The blog is a supporting surface — marketing, SEO, announcements, docs-adjacent content — not the core product.
• You want speed to first publish measured in days, and you accept the vendor's front-end views as a starting point (they're publishable/overridable).
• You are comfortable owning the operational edges: mail deliverability, comment moderation, reCAPTCHA keys, storage symlink, ShareThis snippet.
• You can pin a version and accept a small, single-vendor dependency (145 stars, 0 dependents, one maintainer org). Budget for reading the source, not just the README.
• Legal is fine with a NOASSERTION license field — the README claims MIT, but the declared license does not say so. Get this confirmed in writing before shipping it in anything customer-facing.

Look elsewhere or build when:

• The blog is core IP or a revenue surface (paid content, gated community, publishing business). You want your own content model, editorial workflow, and rendering pipeline.
• You need content operations beyond one blog: multi-site, structured content, complex taxonomy, revision history with approvals, or localization depth.
• Your stack is not Filament, or you're mid-migration across Filament majors and don't want a third-party gate on that upgrade.
• You need hard SLAs, security review artifacts, or a support contract. This is a community package; there's no evidence of a test suite, and the public route + comment + newsletter surface is real attack surface you'd inherit.
• You want headless/API-first content or a decoupled front end. This ships server-rendered views and routes; a headless CMS is a better shape.

How to Pitch It (Stakeholders)

For executives: This is a time-to-market buy, not a platform commitment. It gives us a working blog — post management, SEO metadata, scheduled publishing, author pages, table of contents, comments, and newsletter capture — in roughly a day of integration instead of a quarter of engineering. It runs inside our existing Laravel/Filament stack with no new service, no new database, and no new vendor contract. The honest caveats: it's a small open-source project from a single vendor with limited community adoption, its license metadata is ambiguous and needs legal sign-off, and the comment/newsletter features make us responsible for moderation and email deliverability. Recommendation: adopt as a reversible bet on a scoped surface, pin the version, and revisit if content becomes a primary growth channel.

For engineering: Standard Laravel package — service provider, publishable config/views/migrations, artisan installer, Blog::make() plugin registration. Ships public routes, front-end views, its own tables (prefixable), configurable user model binding, and a HasBlog trait, so it composes with existing users rather than forking them. Two things to plan for: (1) it's a subsystem with its own request surface and mail pipeline, so treat it as such in review — routes, middleware, reCAPTCHA, storage disk; (2) majors track Filament majors, so pinning and the v2-style table-prefix migration path need to be in our upgrade runbook. Expect to override published views to match our design system.

For marketing/growth: Immediate capability — scheduled campaigns, SEO meta per post, social share, author credibility blocks, and an email capture hook into the newsletter list. First publish can be same-week. Constraint to agree up front: comment moderation policy and consent/unsubscribe language need to be settled before we turn comments and signup on, not after.

Ask: approve a scoped pilot (marketing blog only), one sprint of engineering including view overrides, and a legal check on the license before anything goes to production.