Framework Laravel Package

Product Decisions This Supports

• Build vs. buy for community: Flarum is a decision to not build threading, moderation queues, mentions, notifications, permissions, and search in-house. It replaces an estimated multi-quarter roadmap item with an integration and theming effort.
• First caveat for the decision record: this is not a Laravel package you composer require into an existing app. It is a standalone PHP forum application that uses Laravel/Symfony components (illuminate/database, illuminate/support, etc.) plus a Mithril.js frontend. Treat it as a service you deploy and integrate with, not a library you embed. That distinction changes the ops cost, the integration surface, and who owns it.
• Feature scope: supports a "Community" or "Customer discussions" surface — product Q&A, feature request boards, peer support, changelog discussion, beta feedback cohorts.
• Roadmap sequencing: because it ships an admin panel, extension system, REST/JSON:API, and SSO hooks out of the box, you can launch a community in weeks and defer investment in bespoke community tooling until usage proves out.
• Integration architecture: the JSON:API and authentication extension points make "forum as a satellite service with shared identity" a viable pattern — your product remains the system of record for users, entitlements, and billing; Flarum owns discussion content.
• Extend vs. fork: the extension ecosystem is the primary customization lever. A PM decision here is to budget for extensions and a thin integration layer, and explicitly rule out forking core unless you're prepared to own upgrades forever.
• Risk/opportunity read: the low opportunity score (32.4) is a signal, not a defect — the forum market is crowded and well served (Discourse, NodeBB, hosted Circle/Discourse). Adopt Flarum as infrastructure for a feature, not as a platform you'd build a business on top of or differentiate through.

When to Consider This Package

Adopt when:

• You need a self-hosted, MIT-licensed community surface and want to avoid per-seat or per-MAU hosting fees at scale.
• Your team is already PHP-comfortable (Laravel/Symfony experience transfers; illuminate/* dependencies are familiar territory).
• You need shared identity with an existing product — SSO, user sync, group-to-tag permission mapping — rather than a fully separate login.
• You want fast time-to-first-post with a credible default UX (it is genuinely one of the better-looking default forum experiences in PHP).
• Moderation needs are standard: flags, approvals, suspensions, tags, per-tag permissions — not bespoke compliance workflows.
• You're comfortable owning a PHP service: web server, database (MySQL/Postgres/SQLite), Redis for cache/queue, and a patch cadence.

Look elsewhere when:

• You need a managed SLA with no ops headcount — hosted Discourse or a SaaS community product is the honest answer.
• Your stack is not PHP and you have no appetite for running a second runtime alongside it.
• Requirements lean real-time chat, DMs, or presence rather than threaded discussion — Discord/Slack-style tools, or a chat-first product, fit better.
• You need enterprise compliance depth (eDiscovery, granular audit trails, data residency guarantees) — evaluate Discourse Enterprise or a commercial vendor.
• You need heavy mobile-native community experiences; Flarum's frontend is web-first and custom native clients mean owning the API contract.
• Your differentiator is the community experience. If community is core product, a fork/extend strategy on a third-party core becomes an escalating maintenance tax.
• You can't absorb upgrade work: major-version migrations plus third-party extension compatibility are the recurring cost center, and extension quality across the ecosystem is uneven.

Due diligence items before commitment: maintenance cadence and maintainer concentration, PHP version support window, extension compatibility with the current major, upgrade path from your target version, and whether your must-have extensions are actively maintained or single-maintainer.

How to Pitch It (Stakeholders)

To executives — the one-paragraph version: We can ship a customer community in a fraction of the time and cost of building one, using Flarum: a mature, MIT-licensed, self-hosted forum with 6.7k GitHub stars and an active release cadence. There are no license fees and no per-user pricing, so cost scales with our infrastructure, not our community size. The trade-off is that we operate a PHP service and own upgrades; we are buying a head start on commodity functionality, not outsourcing community strategy. Recommendation: pilot with a single audience segment, measure activation (first post, weekly returning posters) before committing to a broader rollout.

To engineering — the framing that matters: It is a standalone PHP app, not a package to embed. It runs on Laravel/Symfony components with MySQL/Postgres + Redis, exposes a JSON:API, and is customized through extensions plus an auth integration rather than core patches. Budget for: a deployment target, SSO/user-sync work, theme work, and a standing upgrade-and-extension-compatibility line item. The main technical risks are third-party extension maintenance and major-version migration effort — we should pin versions and keep a short, audited extension list.

To finance/ops: MIT license, zero seat fees; total cost is hosting, on-call for one more service, and periodic upgrade engineering. That is a fixed, predictable line — versus a per-MAU SaaS bill that grows with success.