Product Decisions This Supports
- Framing the FAQ capability, not the code. What this package actually represents is a product scope decision: do we treat FAQs as first-class managed content (draft/live states, curated ordering, front-end rendering) or as static marketing pages? The package's feature set — Filament CRUD, drag-and-drop sequencing, publish toggles, Blade components — is a reasonable minimum viable spec for that capability, and it's useful as a scope reference even if we never install it.
- Build vs. buy, resolved cheaply. The honest read is that "buy" is not available here: the package is archived, has zero stars, last shipped in May 2022, and sits at v0.1.5. That collapses the decision to build vs. build-from-this-as-reference. Since the surface area is one resource with two fields, ordering, and a boolean, this is days of work, not weeks — which makes the buy option unattractive regardless of the package's health.
- Trov platform commitment. Adopting anything in the Trov ecosystem is a bet on Trov as our content platform. This add-on is only viable if we've already standardized on Trov and on a compatible Filament major. It's a forcing function to answer that platform question explicitly rather than drifting into it via a small feature.
- Roadmap sequencing for content operations. The publish-toggle and ordering features imply a workflow where marketing or support edits FAQs without engineering involvement. If that self-serve requirement is real, it belongs in the content-ops roadmap and should be solved at the platform layer (a reusable "ordered, publishable content block" pattern) rather than as a one-off FAQ package.
- Reference implementation for a reusable pattern. Questions, answers, ordering, and visibility are the same primitives as testimonials, docs, changelogs, and policy pages. Evaluating this package is really a decision about whether to standardize that pattern once — which is a better use of the evaluation than the FAQ feature itself.
When to Consider This Package
Consider it only under a narrow, low-stakes set of conditions:
- We are already running Trov with a Filament admin panel at the exact major version this targets, and the FAQ feature is a prototype or internal tool where the cost of rework is measured in hours.
- Someone owns it. The archived status means no upstream fixes; any use implies we are prepared to fork it into our own namespace and maintain it ourselves. If we're going to fork it, we should price that against writing the ~200 lines ourselves.
- The dependency review is complete: pinned to the exact
0.1.5 tag, composer.json diffed, PHP and Laravel floors confirmed against our runtime, and the package installed cleanly against our real constraints.
Look elsewhere — or build — when any of the following is true:
- Production dependency. Archived + pre-1.0 + one-line release notes ("Bump dependencies") means no stability contract, no security disclosure path, and no responsiveness signal. That's disqualifying for anything in a production dependency path.
- We're not on Trov. The package is a Trov resource add-on; without Trov and a matching Filament version it delivers nothing.
- The FAQ capability is genuinely small. Which it is. A Filament resource with
question, answer, sort, is_published is a routine build. Buying maintenance overhead to avoid a short build is a bad trade.
- Multi-service rollout is contemplated. Pre-1.0 packages that bump their own constraints become uninstallable alongside pinned framework versions across services on different Laravel majors. The coordination cost exceeds the feature value.
How to Pitch It (Stakeholders)
To executives: We evaluated a free add-on that would let marketing publish and reorder FAQ content from our existing admin panel. The feature is real and the scope is small, but the package itself is effectively abandoned — archived, last updated in 2022, still pre-1.0, with release notes that don't tell us what changed. I'm not recommending we adopt it. I am recommending we take its feature list as the spec and build the equivalent ourselves inside our existing admin, which is a short piece of work with no ongoing dependency risk. The decision to make is whether self-serve FAQ editing is worth doing at all this quarter; if it is, the build is straightforward and the vendor question is closed.
To engineering: Treat this as a reference implementation, not a dependency. If you want to move faster, a sandbox install pinned to 0.1.5 is cheap and will show you the shape of the resource in an hour — but do not put a ^0.1 constraint anywhere near production, and read the composer.json diff before installing, because "bump dependencies" can mean a raised PHP floor or a dropped Laravel major with no note saying so. My default recommendation is to reimplement the resource — question, answer, sort order, publish toggle, plus a Blade partial — and own it outright. It's small enough that forking someone else's abandoned 0.x code is the more expensive option over a twelve-month horizon.