Product Decisions This Supports
- Build vs. buy for Q&A/support workflows.
fof/best-answer is a Composer-installable Flarum extension, not a library you embed. The real decision it informs is "do we adopt the community-standard 'accepted answer' pattern, or build our own solved-state model into the forum?" Adopting it defers ~weeks of design/build work on post-flagging, permissions, and moderation UI.
- Feature parity with user expectations. Users arrive from Stack Overflow, Discourse ("Solved"), Reddit, and vendor support portals expecting a thread to declare an answer. Shipping this closes a known expectation gap without a custom roadmap item.
- Self-serve support deflection. A visible best answer turns a solved thread into reusable documentation, reducing repeat questions and moderators' "see this thread" replies. This supports support-cost and community-health OKRs more than it supports product-usage metrics.
- SEO and content-surface decisions. Marking a canonical answer enables
AcceptedAnswer/QAPage-style structured data work and cleaner "solved" indexing — relevant if organic search is a meaningful acquisition channel for your docs or forum.
- Roadmap scoping for a support community. If a Q&A community is on the roadmap, this is a day-one config decision rather than a later migration. If your forum is discussion- or community-shaped (not resolution-shaped), it should not be on the roadmap at all.
- Metrics instrumentation choice. The extension gives you a solved/unsolved signal per discussion, which is the prerequisite for time-to-resolution and answer-rate dashboards. Decide up front whether you will export that state to your warehouse, because the extension itself is not an analytics product.
When to Consider This Package
Consider it when all of the following hold:
- You are running (or committed to) Flarum as your community/support platform. This package has no value outside Flarum; it is not a generic PHP/Laravel library despite the Composer/PHP packaging.
- Your content is question-shaped — users post problems expecting a resolution, not open-ended discussion.
- You want a fast, low-cost pilot rather than a differentiated feature. The extension is MIT-licensed, so there is no procurement or legal review cycle, and no per-seat cost.
- You can accept community-maintained software under the FriendsOfFlarum umbrella. That org has a good track record, but this is not first-party Flarum core and not a commercially supported product.
Look elsewhere — or build — when:
- Adoption signal matters to your risk model. 26 stars and 0 dependents is a thin signal. Note that "dependents" is a weak metric for Flarum extensions (they are installed, not required by other packages), but the star count still says "niche." Verify Flarum version compatibility and recent commit activity yourself before committing.
- You need more than one accepted answer, per-answer voting, answer ordering, or answer-level analytics. The package models a single best-answer flag; anything richer is custom work.
- You need SLA tracking, ticket lifecycle, or CRM integration (Zendesk, Salesforce, Intercom). This is a forum affordance, not a support-desk system.
- You need vendor SLAs, security review, or indemnification. MIT + volunteer maintenance means you own the fork if it breaks.
- Your community is conversational — fan forums, feedback boards, changelogs. A best-answer marker adds moderation overhead and implies closure where none exists.
- Your stack is not Flarum. Do not stretch this into a Laravel decision; there is no Laravel integration surface here.
How to Pitch It (Stakeholders)
To executives (one paragraph): We can close a well-understood gap in our community experience — the ability to mark a post as the answer — with a free, MIT-licensed, config-only extension rather than a build project. It costs roughly an afternoon of engineering and a design review, carries no licensing or vendor cost, and gives us a "solved" signal we can use to reduce repeat support questions and expose cleaner structured data to search engines. The trade-off is maintenance risk: it is community-maintained with modest adoption, so we should treat it as a reversible pilot, pin the version, and be prepared to fork or replace it. Recommendation: pilot on one category, measure answer-rate and repeat-question volume over 30 days, then decide on broader rollout.
To engineering: Small surface area. A Flarum extension registered via Composer, MIT, no new infrastructure, no data migration beyond its own tables, and it respects Flarum's existing permission model. Ask them to confirm Flarum core version compatibility, review the migration and permission gates, and decide whether best-answer state needs to be mirrored into our analytics pipeline — that export is the only real integration work.
To design/community: This changes thread affordances and moderator workflow. Expect to define who can mark an answer (author, moderator, both), how un-marking works, and what "solved" looks like in list views and notifications. Scope those decisions before install; they are product choices, not configuration defaults.
What would change the recommendation: a Flarum core roadmap commitment to native solved-state, a materially higher-traffic launch where thin-adoption risk is unacceptable, or a requirement for multi-answer/answer-voting — any of which moves this from "buy/adopt" to "build or wait."