Filament Knowledge Base Laravel Package

Product Decisions This Supports

• Build vs. buy for in-product help. The knowledge base, article/category CRUD, drag-and-drop ordering, rich-text/Markdown authoring, searchable frontend routes, SEO slugs and visibility controls already exist as native Filament resources. The PM decision moves from "do we staff a help-center build?" to "do we fund a two-sprint pilot and assign a content owner?" — a materially cheaper question with a faster answer.
• Support deflection and onboarding roadmap. Gives product a shippable delivery mechanism for FAQs, troubleshooting guides and "how do I…" content inside the tool operators already have open. The bet only pays off where ticket volume clusters around repeatable questions; complex one-off escalations are unaffected and should not be used to justify the investment.
• Feature-launch enablement as a checklist item. Because authoring lives in the same admin panel the team already uses, "publish the help article" can become a line item in the launch checklist rather than a post-launch scramble. The highest-leverage pattern is contextual deep-linking from the exact screen where a user is stuck to a specific article slug — an article nobody can find from the failing form is not deflection, it's documentation debt.
• Content ownership and operating model. Adoption forces an explicit answer to who writes, who reviews, how often, and how stale content gets retired. Recommend product/support operations own content with a named reviewer and a quarterly freshness pass; engineering owns version pinning and upgrades. Without a named owner, the KB becomes a graveyard of outdated screenshots within a quarter and quietly damages trust.
• Panel standardization. In multi-panel Filament estates (an admin authoring panel plus customer/operator read panels), decide whether one shared help experience beats duplicated Notion pages, Loom links and Confluence spaces. Accept the known constraint up front: the plugin registers per panel, so a "one KB everywhere" goal is deliberate configuration work, not a default.
• Access model as a product decision, not a plugin setting. Draft/published states and role-based access exist, but the read-vs-author split is enforced through your own policies and permissions. That means product must define who may read help, who may author, and who may publish — a governance decision the package surfaces rather than solves.
• Measurement scope. The package does not appear to ship analytics. Article usage, search-with-no-results, ticket deflection, time-to-first-action and support-contact rate are product work you must instrument yourself. Treat instrumentation as part of the pilot's cost, not an afterthought — otherwise "did this work?" becomes an opinion.
• Dependency risk posture. Zero recorded dependents and a 0.3 score mean this is an unproven dependency. Position it as a contained, version-pinned pilot with a documented exit ramp — keep article bodies in version-controlled Markdown and the model thin (slug, title, category, body) so migrating to a forked resource, a static docs site, or your own CRUD is a data copy plus a route-helper change rather than a rewrite. Do not make it load-bearing for external-facing documentation.
• Sequencing insight. The 3.3.2 release was a merged community translation — thin evidence, but evidence of some maintenance and i18n motion despite the weak adoption signal. Enough to justify a spike; not enough to justify a roadmap commitment or a headcount ask.

When to Consider This Package

Consider it when:

• You already run a Laravel + Filament panel, and help content would otherwise live in tools users don't open when they're stuck.
• The audience is internal or operator-facing — admin self-service, back-office staff, partner portals — rather than public marketing documentation.
• You want an MVP in days, not quarters, and can tolerate community-package maturity and a small maintainer surface.
• Your team can read the package source, pin to a tested minor range (^3.3) rather than floating, re-publish config and migrations on upgrade, and own a fork if maintenance stalls.
• You can complete a single end-to-end validation pass within a timeboxed spike — publish migrations, register the plugin on one panel, create one category and one article, confirm the reader view renders, and verify a permission check actually denies the wrong user.
• You can instrument success yourself, since deflection and usage metrics are not native.

Look elsewhere when:

• You need enterprise SLAs, audit trails, granular RBAC, or formal vendor support guarantees.
• Requirements include multilingual content workflows, advanced search (Scout or an external engine, relevance tuning), or high-scale public documentation with real SEO stakes.
• The content must be public-facing and crawlable — this is a panel plugin, not a docs platform; reach for a dedicated docs tool.
• You run multi-tenant panels and cannot absorb the extra work of adding tenant_id and scoping slug uniqueness — otherwise route-model binding can resolve the wrong tenant's article.
• No one can own upgrades. Filament majors move quickly, and a fast-moving pre-1.0-style Guava package demands disciplined dependency hygiene.
• Compliance requires a security review and sanitization guarantee for author-supplied HTML/Markdown before any user sees it — editor output is not automatically safe for untrusted readers, so purification on output becomes your responsibility.

How to Pitch It (Stakeholders)

Executives. We can stand up a self-hosted help center inside the admin tools our teams already use for roughly the cost of a short spike instead of a build. The thesis is simple: fewer repeatable support tickets and faster onboarding, measured against ticket deflection and help-article usage. The caveat is honest — the package has no public dependents and a thin adoption signal, so I'm recommending a contained pilot on one high-friction workflow with named success criteria, pinned versions and a rollback path. Worst case we lose a sprint and learn where our users actually get stuck; best case we retire a recurring ticket category and gain a repeatable launch-enablement step.

Engineering. This is a Filament plugin adding article and category resources plus a reader frontend to a panel — migrations, routes, policies and views come with it, and registration is per panel. The ask is small and bounded: install, publish config and migrations, register on the admin panel, then do one create-and-render pass and confirm route:list matches the configured prefix before we author anything real. Known constraints we should plan around: no tenancy in the base schema, sanitization of author-supplied HTML is ours to handle, and cache behavior may delay edits reaching readers. We pin to a tested minor, keep article bodies as Markdown files in the repo, and re-publish config and migrations with a diff on each upgrade so we catch renamed keys before staging does.

Content and support operations. You get an authoring surface inside the tool you already use, with categories, draft/published states and search. What we need back is an owner, a review cadence, and a bias toward short, task-specific articles tied to the screens where people get stuck — plus the discipline to retire stale content. If we skip that, we ship a knowledge base nobody trusts, which is worse than shipping none.