Statamic Community Laravel Package

Technical Evaluation

Architecture fit

• The package is a Laravel/Composer addon sitting on top of Statamic and goldnead/statamic-teams ^0.4. It therefore inherits the Statamic architecture (flat-file content layer over Eloquent/Blade, addon registration through service providers, config publishing, CP nav registration) rather than being a framework-agnostic library.
• Appropriate only for teams already standardized on Statamic. For a pure Laravel application (no Statamic CP, no flat-file content), the dependency footprint — Statamic core plus a pre-1.0 teams addon — is disproportionate to whatever functionality is gained.
• The teams/permissions domain is cross-cutting: it typically touches user models, middleware, authorization policies, and the CP. Anything that instruments that layer has a wide blast radius and is hard to trial in isolation. Treat it as an architectural decision, not a utility dependency.

Integration feasibility

• v0.1.1 is the first installable release. The 0.1.0 defect was not cosmetic: requiring a dev branch and setting minimum-stability: dev at the package level, if honored by the consuming root project, would have loosened stability constraints across the entire dependency graph, not just for this package. That is a supply-chain-grade problem in a locked enterprise build, and it is the single most important fact about this release.
• With the fix, a normal composer require against Packagist should work. Integration effort is now ordinary: publish config, run migrations if any, register middleware, seed roles.
• Remaining feasibility question is constraint satisfaction — PHP version, Laravel major, Statamic major, and goldnead/statamic-teams ^0.4 must all intersect with the target project. That is unverifiable from the release note alone.

Technical risk

• Pre-1.0 status (high): 0.1.x carries no compatibility promise. The package has no demonstrated production usage; 0.1.0 could not be installed, so v0.1.1 is effectively a first release with zero real-world install base.
• Transitive pre-1.0 dependency (high): ^0.4 on goldnead/statamic-teams means the caret only allows >=0.4.0 <0.5.0. A 0.5 release — which is where a pre-1.0 addon would typically make breaking schema or config changes — will not be picked up automatically, and a security or Statamic-compatibility fix landing in 0.5 strands this package.
• Maintenance concentration (medium-high): two packages, apparently under one vendor, both before 1.0. Bus factor is likely one.
• Upgrade coupling (medium): upgrades to Statamic majors will require a coordinated release of both this package and statamic-teams.
• Silent-stability regression (low now, worth a guard): the defect class is a root composer.json policy mistake. A CI job that asserts minimum-stability and prefer-stable in the committed lock file catches recurrence cheaply.

Key questions for the maintainer

1. What does this package add over goldnead/statamic-teams directly — is it a thin adapter, or does it own behavior?
2. Exact support matrix: PHP, Laravel, Statamic, and statamic-teams versions tested.
3. Is there a CI matrix? Test suite coverage of the permission/authorization paths specifically?
4. Is goldnead/statamic-teams maintained by the same author, and what is its release cadence?
5. Licensing and commercial terms — Statamic addons are frequently paid; confirm before procurement.
6. Roadmap to 1.0, and what constitutes a breaking change under 0.x.
7. Data model: does it add tables or migrations, and how are those rolled back?

Integration Approach

Stack fit

• Target profile: Laravel 10/11 application running Statamic 4/5, single-tenant today with a plausible multi-tenant or client-portal requirement, already comfortable with Composer-based addon installation and config publishing.
• Explicit non-fit: headless Laravel APIs, Laravel apps without Statamic, and any environment with a signed-off dependency policy that disallows 0.x packages in production.

Migration path

• There is realistically nothing to migrate from. 0.1.0 could not be installed from Packagist, so the only affected cohort is developers who pulled the dev branch manually.
• For that cohort: remove the dev-branch constraint and any package-local minimum-stability: dev / prefer-stable: false from the root composer.json, re-resolve, and audit the resulting composer.lock diff. Expect the lock diff to be larger than the package itself — that is the point of the audit.
• No database or content migration is implied by the release note; confirm whether 0.1.1 ships migrations at all.

Compatibility

• Verify the resolved graph before writing code: PHP constraint, Laravel constraint, Statamic constraint, and goldnead/statamic-teams at a version inside ^0.4.
• Check whether Statamic's addon licensing/edition (e.g., Pro features) gates any of the intended functionality.
• Confirm the package's service provider supports Laravel package discovery; if not, manual registration is required and should be captured in the runbook.

Sequencing

1. Spike (1–2 days): install into a throwaway Laravel + Statamic project on the target versions. Success criterion is a clean composer require with minimum-stability: stable intact in the root.
2. Constraint audit: diff the lock file, record every transitive addition, check licenses.
3. Functional pilot: wire the teams/permissions flow into one non-critical internal feature; confirm CP behavior and authorization middleware behave as documented.
4. Security and compliance review: dependency policy, license, maintainer reputation, CVE scan.
5. Production decision: only after a Statamic major upgrade has been rehearsed at least once with this package in the graph, or with a documented rollback.

• Do not sequence this alongside a Statamic major upgrade or an unrelated auth refactor. Combined failures here are expensive to attribute.

Operational Impact

Maintenance

• Budget for churn. A 0.1.x package should be assumed to change shape; pin to an exact patch version (0.1.1, not ^0.1) and upgrade deliberately.
• The ^0.4 constraint will require manual attention when goldnead/statamic-teams reaches 0.5+. Add a calendar reminder or a Renovate/Dependabot rule with auto-merge disabled for this line.
• Track upstream Statamic releases; each Statamic major will need a corresponding release here, and the gap between them is a window where you cannot upgrade Statamic.

Support

• Assume no vendor SLA. Support is GitHub issues on a volunteer cadence, mediated by a pre-1.0 API. Internal ownership must be named — one engineer accountable for this integration, with a documented fallback to implementing team permissions directly.
• Escalation path is essentially "fork it." Confirm the license permits that before adoption.

Scaling

• Statamic's flat-file storage means team-scoped content queries can degrade as content volume grows; benchmark the intended access pattern (list teams, resolve a user's teams, filter content by team) against realistic volumes rather than assuming Statamic's caching covers it.
• Authorization checks typically run per request; if the teams resolver hits disk or an uncached query each time, that is a per-request cost across the whole app. Cache the resolved team context per request at minimum.

Failure modes

• Composer resolution failure in CI or another developer's environment due to a stability flag mismatch — highest likelihood, cheap to detect with a lock-file assertion in CI.
• Stranded on an old statamic-teams because the ^0.4 caret refuses 0.5, blocking a Statamic security patch.
• Authorization regression — permissions logic failing open rather than closed is the material risk, and a 0.x package with unverified coverage is where that risk lives.
• Abandonment — upstream goes quiet, and the package becomes a pinned liability that gates Statamic upgrades.
• Blast-radius failures touch authentication and access control, so contain the pilot to a non-critical feature and gate production behind a rollback plan.

Ramp-up

• Low for engineers already fluent in Laravel service providers, config publishing, and Statamic's CP conventions — on the order of half a day to a working local install, a day or two to productive use.
• Non-trivial for engineers without Statamic experience: the flat-file content model and the addon/edition concepts are the real learning curve, not this package.
• Cost is dominated by the constraint audit and permission-model design, not by installation. Plan the former before committing the latter.