Collaboration Laravel Package

Product Decisions This Supports

• Sequential vs. concurrent authoring — a strategy call, not a plugin purchase. Statamic's flat-file model defaults to "last save wins." Adopting this addon is a deliberate decision to close that gap against SaaS CMSs (Contentful, Sanity, Storyblok) rather than investing further in draft/review/publish workflows. Name it as an editor-experience bet in the decision log, because it determines where the next three sprint cycles of content-ops work go.
• Build vs. buy for the real-time layer. Presence tracking, channel authorization, reconnection and state reconciliation, and stale-presence cleanup are deceptively expensive to build on Laravel — the visible feature is three avatars, the invisible work is websocket lifecycle management. The buy case is strong: a vendor addon converts an open-ended engineering project into a license line item plus an infrastructure dependency. Make that trade explicit rather than discovering it mid-build.
• Platform standardization and lock-in. Statamic-only, Pro-only, control-panel-only. Adoption deepens commitment to the CMS (retention upside for editors) while raising switching cost (optionality downside). Decide that consciously — it is rarely the stated reason a team adopts, and always a consequence.
• Prioritization against other content-ops features. Real-time presence competes with approvals, scheduled publishing, localization workflows, and audit trails. For an enterprise editorial team it's table stakes; for a two-person content team it's a solution looking for a problem. Rank it against measured overwritten-revision incidents, not against a competitor's feature page.
• Rollout scope is itself a product decision. The architecture supports config-gated enablement per environment, per collection, per site. That means you can commit to a phased pilot without committing to a global launch — a cheap way to buy information before buying the platform bet.
• Use cases that justify the spend: agencies with multiple editors on a shared landing or campaign page; news and event publishing under deadline; large marketing sites where the homepage or pricing page is a permanent collision surface; multi-site localization teams editing the same entry set. The v2.0.1 multi-site fix (#115) moves multi-site teams from "pilot with caveats" to "viable pilot candidate."
• Portfolio posture: pilot candidate, not default. 36 stars and zero dependents is a thin adoption signal. The 2.0.1 fixes are authored by Statamic core maintainers (@jackmcdade, @jasonvarga), which upgrades the support signal to vendor-backed but does nothing for the adoption signal. Treat those as two separate axes in your risk register.

When to Consider This Package

Adopt when all of the following hold:

• You run Statamic Pro and intend to stay. This is a control-panel addon — there is no meaningful integration path in a stock Laravel app. The first task is a prerequisite check, not an engineering spike.
• You have, or will fund, an operable broadcast stack: self-hosted Laravel Reverb, Pusher, or Ably. This is the real cost center and the usual reason pilots stall. Budget operational ownership (supervised service, monitoring, restart runbook) or budget a vendor SLA — pick one deliberately.
• Your editing pattern produces genuine concurrent-edit collisions: multiple editors, same entry, same locale, same window. If editors work sequentially by convention, presence indicators buy you very little.
• You can run a bounded pilot behind a config flag, staged one collection → one site → all editors, with a documented rollback that costs a config flip rather than a deploy.
• You are on >= 2.0.1 if multi-site. #115 is the single most relevant fix; below it, multi-site is disqualifying. 1.x → 2.x is its own work item with its own test pass, not a footnote.

Look elsewhere when:

• Procurement can't clear the Pro license. Hard requirement, not negotiable.
• The real gap is workflow, not presence. Approvals, audit trails, granular permissions, and scheduled publishing are not solved here. Extending this package to cover them is a build project wearing a vendor costume — buy it for presence, build workflow elsewhere.
• There is no appetite for websocket uptime as a production dependency. Hosted Pusher or Ably converts that into a vendor SLA line item: money traded for ops burden, which is legitimate but must be in the budget conversation, not discovered in month two.
• Your storage layer can't be trusted with concurrent writes. Statamic stores content as flat files; file-locking semantics on NFS/shared storage are unreliable. If production runs on network storage, validate simultaneous saves against that storage in staging first. This is the most likely data-loss path and the addon cannot insulate you from it.
• You need hard locking or character-level co-editing. This is advisory presence with conflict warnings. Selling it internally as "Google Docs for our CMS" will produce a stakeholder expectation you cannot meet.

How to Pitch It (Stakeholders)

For executives — one paragraph: Our editors lose work when two people open the same entry and the last save silently overwrites the first. This addon surfaces who is editing what, in real time, and warns before an overwrite — the same baseline behavior editors already expect from Contentful and Sanity. It's a small, vendor-maintained extension to Statamic built by the CMS's own core maintainers, so it's a license plus an infrastructure line item rather than an engineering project. We propose a gated pilot on one collection and one site with a config-level kill switch, clear success metrics, and pre-agreed kill criteria — so the downside is bounded to a few weeks of ops attention, not a platform commitment.

For engineering — the honest brief: Presence channels, Echo wiring, and channel authorization are someone else's problem now. Yours are the things the addon doesn't own: broadcast server uptime (Supervisor/systemd unit, monitoring, restart procedure), CSP connect-src and reverse-proxy Upgrade headers, and channel authorization that actually inherits Statamic's permission model rather than silently exposing presence to users without edit rights. Confirm the editor degrades gracefully to plain Statamic when Reverb is stopped — if it hard-fails, the kill switch needs to be wired to a health check before launch, not after.

Acceptance criteria — the two-window test: open the same entry as two different Statamic users in two browsers. Verify presence appears for both, the "someone else is editing" warning fires, closing one tab clears presence within a reasonable window, and stopping the broadcast server degrades quietly. Run it on a multi-site tree, not a single-site install. That single test exercises roughly 80% of what fails in production, and it's automatable with Dusk or Playwright against two authenticated sessions.

Metrics and kill criteria — write them into the ticket now: measure overwritten-revision incidents before and after, plus editor-reported collision near-misses. Agree in advance that we stop if there's no measurable drop in overwritten revisions after 60 days, or if websocket operational burden exceeds the collaboration value delivered. A config-flag rollback is the main architectural insurance this purchase provides — use it as a decision tool, not a postmortem artifact.