Statamic Messaging Laravel Package

Product Decisions This Supports

• Multi-tenant / team-scoped content in Statamic: the package sits on top of goldnead/statamic-teams, so it is a candidate wherever the roadmap calls for per-team or per-client content, roles, and CP scoping rather than a single flat site.
• Build vs. buy for team/permission plumbing: adopting it defers building bespoke team models, invitations, and permission gates — worth pricing against 2–4 sprints of internal work plus ongoing maintenance.
• Roadmap sequencing: v0.x with a 0.x upstream dependency means it belongs in an experiment/spike slot, not a committed customer-facing milestone. Fund a time-boxed spike before promising team features to sales.
• Agency / multi-site use cases: strongest fit is client portals, franchise or branch sites, and SaaS-style onboarding where Statamic is already the CMS — this is where team scoping is a differentiator rather than overhead.
• Defer the "extend vs. fork" decision: a pre-1.0 release and a recent packaging break mean the extension seams are not yet stable; budget for direct vendor conversations before building on internals.

When to Consider This Package

Consider it when all of the following hold:

• Statamic is already the chosen CMS and the team feature is genuinely needed, not speculative.
• The dependency on goldnead/statamic-teams is acceptable to you as a runtime dependency — and you are willing to track its 0.x releases too, since this package pins ^0.4. Two pre-1.0 packages in a chain is two upgrade surfaces.
• You can tolerate API churn: expect breaking changes on any minor bump until 1.0. Pin exact versions and read changelogs before every update.
• You have a fallback: either a clean abstraction layer around team logic, or the in-house capacity to take over maintenance if the package stalls.

Look elsewhere when:

• You need a support contract, SLA, or a dependency you can put in front of enterprise procurement. Pre-1.0 with a pre-1.0 upstream will not survive most vendor-risk reviews.
• Your requirements are a thin slice of permissions (e.g. simple role checks). Laravel policies plus Statamic's built-in permissions are cheaper than a second 0.x dependency.
• The team feature is load-bearing for revenue and you cannot staff a maintenance contingency.
• You are not on Statamic — nothing here transfers to a plain Laravel app without that foundation.

Version-specific caveat for this release: v0.1.1 fixes a composer.json that required a dev branch and set minimum-stability: dev, which made 0.1.0 effectively uninstallable from Packagist. The fix is welcome and unblocks evaluation, but it also tells you something: the first tagged release shipped without a Packagist install test. Before committing, verify there is CI that actually runs composer install from the registry, that tests exist and pass, and that the maintainer responds to issues. Absence of those is a stronger signal than the changelog.

How to Pitch It (Stakeholders)

Executives: "This is a small add-on that gives Statamic team and multi-tenant capabilities — useful for client portals and SaaS-style products, and cheaper than building permissions from scratch. It is early-stage (v0.1) and depends on another early-stage library, so I recommend a short, low-cost evaluation rather than a roadmap commitment. The immediate upside is that the version published this week is actually installable; the previous one was not, which is our cue to validate maturity before we depend on it."

Engineering: "v0.1.1 corrects the packaging error in 0.1.0 — minimum-stability: dev and a dev-branch requirement for goldnead/statamic-teams are replaced by stable and ^0.4, so it can now be pulled from Packagist. Treat it as pre-1.0: pin exact versions, expect breaking changes on minors, and note we inherit the 0.x upgrade cadence of the upstream teams package. First task is a spike — install clean, confirm tests and CI, and wrap the team API behind our own interface so a stall or a breaking release isn't a rewrite. If the spike shows thin test coverage or no release automation, we either budget for ownership or drop it in favour of native Statamic permissions."