Product Decisions This Supports
- Release communication discipline. Gives PMs a structured place to capture "what shipped" at merge/release time instead of reconstructing it weeks later from PRs and Slack threads. It is a direct input to "how do we talk about releases, and to whom?"
- Build vs. buy for changelog tooling. A DB-backed changelog admin scoped to a Filament panel is typically 1–3 days of engineering. This package reframes the decision as "adopt, audit, and effectively own a 4-star MIT plugin" vs. "build a small internal CRUD." For a solo dev or pre-PMF product, adoption can save a sprint; for most teams build-or-fork wins on risk.
- Roadmap transparency and customer trust. If surfaced publicly, it forces useful decisions: how much of the roadmap do we expose, do we commit to dates, do we segment messaging by plan tier.
- In-app "What's new" / retention lever. The database-backed model makes announcement banners, release feeds, or digest emails feasible from one source of truth — a cheap engagement experiment rather than a new system.
- The hybrid file + DB model is the actual product idea. Keeping
CHANGELOG.md in the repo (developers, Git history, PR review) while letting non-engineers edit through an admin UI serves two audiences with one workflow. That dual-audience design is the differentiator worth evaluating.
- Explicitly not supported by it: readership analytics, per-customer targeting, localization at scale, or Linear/Jira-driven entry drafting. Those remain separate roadmap decisions.
When to Consider This Package
Adopt or pilot when:
- Your admin stack is already Filament (Laravel) and you want a changelog screen without standing up a new app.
- You already follow — or want to enforce — Keep a Changelog conventions (Added / Changed / Fixed / Removed / Security).
- The changelog is internal-first or low-stakes public: a broken render is annoying, not revenue-impacting.
- You have engineering capacity to read the source, pin a version, and fork if needed. At 4 stars and 0 dependents, you are the de facto maintainer.
- You want to prototype an in-app release feed quickly and defer the keep-or-kill decision.
Look elsewhere when:
- You need a supported dependency — SLA, security response, documented upgrade path. This is a solo, early-stage package.
- You need a marketing-grade public changelog. Hosted tools (Beamer, Headway, Canny, Featurebase) or a docs site (Docusaurus, Astro) do more on subscription capture, SEO, and analytics.
- You need issue-tracker integration to draft entries automatically.
- You are not on Filament, or on a version outside the plugin's supported matrix.
- You operate in a regulated or compliance context where release notes are audit artifacts and you need a vendor with a security posture.
- You are large enough that a 1–3 day internal build is cheaper than the vendor-risk review this adoption would trigger.
How to Pitch It (Stakeholders)
Executives / leadership (30 seconds): This is a small, free (MIT) plugin that adds a changelog editor to our Filament admin panel and keeps CHANGELOG.md in the repo in sync. It is a low-cost experiment in making release communication consistent — not a platform commitment. The real risk is maintenance: it is early-stage, with a tiny user base and no dependents, so I'd recommend a time-boxed pilot on an internal or low-stakes changelog, owned by one engineer, with the expectation that we fork it if it goes quiet. If the pilot shows people actually read release notes, we escalate to a proper public changelog tool with analytics and segmentation. If not, we've spent a sprint and learned something concrete.
Engineering: It's a thin Filament resource over a changelog table plus a file generator — a small surface area to audit, MIT-licensed, easy to vendor or fork. The hybrid model means we don't lose CHANGELOG.md in Git, so PR review and release notes stay one habit rather than two. Questions to settle before adoption: does it pin compatibility to our Filament/Laravel versions, how does it handle concurrent edits and file-write conflicts, and who owns upgrades? If those answers are acceptable, adopting is cheaper than building the equivalent CRUD and Markdown renderer.
What we're actually buying: a convention (Keep a Changelog) and a workflow (PM edits in the UI, developers get a file) — not a vendor. The price is right; the cost is ownership.