Statamic Community Laravel Package

Product Decisions This Supports

• Team/workspace features in a Statamic-backed Laravel product: this package layers on goldnead/statamic-teams (^0.4), so it is the natural lever for shipping team membership, per-team content scoping, and role-based access without building those primitives from scratch.
• Build vs. buy: the "buy" side of the ledger. Adopting it converts weeks of multi-tenancy and permission plumbing into a Composer dependency plus integration work; the trade-off is inheriting a pre-1.0 API surface and a second addon's release cadence.
• Roadmap sequencing: it enables B2B/agency-tier packaging (workspaces, client portals, seat-based plans) to be scheduled earlier, since the team model arrives with the package rather than as a prerequisite epic.
• Packaging/distribution decisions: v0.1.1 removed a hard blocker — composer.json previously pinned goldnead/statamic-teams to a dev branch and forced minimum-stability: dev, making 0.1.0 uninstallable from Packagist. That is the difference between "evaluate in a spike" and "cannot be a dependency at all," so it directly affects whether this can enter a production dependency graph.
• Risk posture on internal standards: because consuming it previously required relaxing minimum-stability, adopting it now also means confirming your own Composer stability policy stays stable — a governance decision, not just a technical one.

When to Consider This Package

Consider it when:

• Your application is Laravel + Statamic and the team/workspace concept maps onto Statamic's content model rather than sitting beside it.
• You need team membership, invitations, and scoped content access as enabling infrastructure, not as a differentiated feature you'd rather own.
• You are comfortable taking a 0.x dependency — the package itself is at 0.1.x and depends on goldnead/statamic-teams at ^0.4, so both sides are pre-1.0 and APIs may move.
• Your Composer setup runs on stable minimum-stability and can resolve the ^0.4 constraint cleanly; v0.1.1 is the first release where that is true, so any earlier evaluation attempt should be re-run rather than trusted.
• A time-boxed spike is enough to validate fit before committing; the version number argues against betting a launch date on it.

Look elsewhere when:

• You are not on Statamic, or your tenancy model requires database-level isolation rather than addon-level scoping.
• You need enterprise RBAC guarantees — audit trails, SSO/SCIM, contractual API stability — which a 0.x package cannot offer.
• The dependency chain is a problem: you already pin goldnead/statamic-teams to a different major/minor, or you need to control that addon's version independently of this package's choices.
• Team functionality is a core differentiator; in that case the build path keeps the data model and permission semantics under your control.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost package that supplies team and workspace functionality on top of our existing Laravel/Statamic stack — the kind of capability that usually shows up as a multi-week build when we price a B2B or agency tier. The new 0.1.1 release is a packaging fix, not a feature release: the previous version required a development branch and a relaxed Composer stability setting, which meant it could not actually be installed from Packagist at all. That blocker is gone, so this is now genuinely evaluable. The caveat is maturity — the package is at 0.1.x and depends on a 0.4.x addon, so treat it as promising infrastructure to prototype, not a foundation to promise dates against.

For engineering: v0.1.1 changes only composer.json — goldnead/statamic-teams moves from a dev branch to ^0.4, and minimum-stability returns to stable. No code, schema, or API changes, and no breaking changes. Practically, this means: 0.1.0 was uninstallable, so discard any earlier "doesn't install" findings and re-run the spike against 0.1.1. Confirm our root minimum-stability stays stable, verify the ^0.4 constraint resolves against our lockfile, and check whether the addon's 0.4 line has its own upgrade path before we build on it. Given two pre-1.0 dependencies in the chain, isolate the integration behind our own interface so a version bump is a contained change.

Recommendation: proceed to a scoped evaluation on 0.1.1; do not commit to a release date until the addon dependency and the 1.0 roadmap are understood.