Filament Team Chat Laravel Package

Product Decisions This Supports

Build vs. buy for in-app collaboration. The core decision this package informs is whether chat inside your admin/product surface is a differentiator or table stakes. If it's table stakes, this replaces an estimated multi-month build (channels, DMs, threads, reactions, mentions, attachments, read receipts, search, notifications — roughly 8–12 core entities and 8 Livewire components) with a composer require and two migrations. If chat is your product, this is a reference implementation, not a foundation.

Scope-cutting on the roadmap. Every feature you don't have to build is a quarter you don't spend. This package's feature list can be triaged directly against your backlog: threads, @here/@channel mentions, unread badges, file previews, full-text search, channel archiving. Decide which you actually need, then check whether the package's default behavior is acceptable — because in a drop-in package, "acceptable default" is the real acceptance criterion, not "best-in-class."

Whether to invest in a notifications/inbox layer. Chat is the highest-frequency notification surface most internal tools never ship. Unread counts + database notifications for mentions and DMs is a legitimate roadmap bet for a multi-tenant B2B admin panel: it turns a tool people must open into one they check. Low cost to test.

Segment and use-case expansion. The features config toggles (v0.5.0) enable a genuine product decision: helpdesk mode — disable channels and threads, keep DMs, mentions, and attachments — turns the same dependency into a support inbox for client-facing portals. Combined with modifyAvailableUsersQueryUsing (restricting who appears in DM lists and mention autocomplete, enforced server-side), you can ship a scoped, client-safe conversation surface for agency/franchise multi-tenant panels without a second product.

Data-residency and vendor-risk posture. "No Pusher, no Redis, no WebSocket server, self-hosted" is a compliance-friendly answer for regulated or air-gapped customers who will not approve a third-party chat vendor. That can be a sales enablement decision, not just an architecture one.

Automation and integration roadmap. The programmatic API (SendMessage, ToggleReaction, MarkAsRead, SearchMessages, findOrCreateDirectMessage) means chat is a data source, not just a UI. That unlocks roadmap items — bot-ingested alerts into a #deploys channel, ticket-to-DM escalation, digest exports — at low incremental cost. Evaluate it as an event substrate before committing.

Multi-tenant packaging. Optional team_id scoping with automatic Filament tenant detection means the feature can be priced per-workspace rather than per-seat, or bundled into a higher agency tier without per-tenant engineering work.

When to Consider This Package

Green-light criteria (all should hold):

• You are already on — or have committed to — Filament v5, Laravel 13, PHP 8.3+. This is not a portable library; it is a plugin for one ecosystem. If Filament isn't a locked-in stack decision, the package is irrelevant regardless of quality.
• Your audience is internal or a small, known set of external users (ops teams, staff, per-tenant client groups), not anonymous public traffic.
• 3–5 second latency is acceptable. Polling at 3s (messages) / 5s (sidebar) is fine for async collaboration and wrong for anything that feels like a live ops console, trading desk, or customer support queue with SLA timers.
• Self-hosting is a requirement or a selling point, not an inconvenience.
• Time-to-market beats depth. You need chat this quarter, and you're willing to accept a young dependency to get it.
• You have a PHP/Laravel engineer who can own the integration — including the Tailwind @source step, which is the most common first-run failure and needs a real owner.

Look elsewhere when:

• Real-time is a requirement. No WebSockets means no typing indicators, no sub-second delivery, no reliable presence at scale. Adding a broadcaster means forking or wrapping, at which point you've lost the "zero dependencies" value proposition.
• You're at meaningful concurrency. Polling multiplies DB load roughly linearly with open tabs. Above ~100–200 concurrent chatters, expect to revisit — measure before you commit.
• Mobile is in scope. v0.5.0 added a responsive layout, but there is no native app, no push notifications outside Filament's database notifications, and no offline story. Buy Slack/Teams if mobile is a first-class requirement.
• You need enterprise assurances. 15 stars, 0 dependents, pre-1.0 (v0.5.1), single-maintainer risk, "readme"-level maturity. No SOC 2, no security bounty history, no long-term support commitment. That's not disqualifying for internal tooling — it is disqualifying if a customer's procurement team will ask.
• You need interop. No Slack/Teams bridge, no webhook-in, no public API surface beyond the PHP classes.
• Chat includes voice/video/huddles. Out of scope entirely.

Mitigation if you proceed: pin the version, vendor the package or mirror it internally, budget a fork path, and treat every minor release as a reviewing event (v0.5.0 included migration changes for UUID/ULID keys — set user_key_type before migrating).

How to Pitch It (Stakeholders)

To executives — the one-paragraph version: This is a self-hosted, MIT-licensed team chat that plugs into our existing admin panel using our existing users and database. It delivers the feature set our team would otherwise spend a quarter building — channels, direct messages, threads, mentions, file sharing, search, unread tracking — with no new infrastructure, no per-seat SaaS fee, and no third-party data processor. The trade-off is maturity: it's a young package with a single maintainer and no enterprise backing, so the recommendation is a time-boxed pilot on an internal panel, not a core-system commitment. Target: two weeks of integration to validate, with a clear go/no-go against measured polling latency and our real concurrency.

To engineering — what they're actually signing up for:

• Three-line install (composer, migrations, plugin registration), one trait on User, plus a Tailwind @source addition and an npm run build. The Tailwind step is the only non-obvious one — assign an owner.
• It ships its own tc_-prefixed tables. No migrations against your schema. Clean rollback path: drop the tables, remove the plugin, no data loss elsewhere. That materially de-risks the pilot.
• Everything in the UI is a PHP action class. Prefer those over touching models — they're the de facto public API and the upgrade-safe seam.
• 102 tests with Orchestra Testbench. That's the strongest signal in the whole package for a pre-1.0 dependency — it means the maintainer has a regression harness, which is more than most 15-star packages can claim.
• Known risks: polling DB load under concurrency, a single maintainer, pre-1.0 churn on migrations/config keys, and no WebSocket path if real-time becomes a requirement.

The recommendation, stated plainly: adopt as a pilot for internal team chat inside an existing Filament panel, with a decision gate at 30 days covering (1) measured latency under realistic concurrency, (2) upgrade friction on the next minor release, and (3) whether helpdesk mode holds up for a scoped external audience. Do not position it as the foundation for a customer-facing support product until those three gates pass. Budget the fork as a real, funded option — with 15 stars and 0 dependents, "we are the only production user" is the actual risk, and the mitigation is owning the code, not trusting the roadmap.