Statamic Fa Widget Laravel Package

Product Decisions This Supports

• CMS platform roadmap and upgrade sequencing. v2.0.0 is explicitly aligned to Statamic 5, which makes this release the trigger for a paired decision: upgrade the CMS and this addon together, or stay pinned on the Statamic 4-compatible v1.x line. A PM should treat this as one roadmap item with a single date, not two independent tickets.
• Build vs. buy for content-driven features. Addons in this ecosystem typically cover things a product team would otherwise spec from scratch (content modeling helpers, fieldtypes, editor tooling, integrations). Sourcing a maintained addon shifts effort from build-and-maintain to configure-and-integrate — a real line item in a roadmap with a small team.
• Editor autonomy and content-ops scope. Anything that expands what non-technical editors can do in the control panel directly reduces the number of "content change" tickets that land on engineering and shortens the loop between marketing copy changes and release.
• Feature scoping against CMS capabilities. Before committing to a custom content model, editorial workflow, or multi-site/localization effort, this package defines what's already solved. That caps scope on features that would otherwise be estimated as bespoke development.
• Headless vs. coupled delivery decisions. If the product surface is a Laravel-rendered site or an app with server-rendered content, this is a low-friction fit. If the roadmap points at API-first delivery to multiple clients, this decision should be revisited rather than assumed.
• Vendor and dependency risk accounting. A major version bump is the moment to re-evaluate maintainer activity, release cadence, and license terms — cheap to do now, expensive to discover mid-quarter.

When to Consider This Package

Adopt when:

• The stack is already Laravel + Statamic, or you're committing to Statamic 5 as the CMS. Platform alignment is the dominant criterion here — this addon is a native fit, not a bolt-on.
• You're on (or moving to) Laravel 11 / PHP 8.2+, the floor Statamic 5 establishes. Verify the exact constraint in composer.json before promising dates; the runtime bump is often the longest-lead item in the upgrade.
• The capability it provides is on the roadmap and would otherwise be built in-house — and it's not a differentiator. Commodity content tooling should be bought.
• Your content team is non-technical and needs control-panel workflows rather than developer-mediated changes.
• You can absorb a major-version upgrade with a staged rollout: pin in composer.lock, test in staging against real content, then promote.

Look elsewhere when:

• You're staying on Statamic 4 for now. v2.0.0 is a major bump; a major usually signals dropped support for the previous CMS line. Confirm whether v1.x will continue receiving security fixes before assuming you can defer indefinitely — an unsupported branch on a public-facing site is a risk, not a saving.
• The core CMS already covers the need. Addon sprawl is a maintenance tax. If Statamic's built-ins or a few dozen lines of app code get you there, prefer that.
• You need API-first/headless delivery as the primary mode. Statamic can do it, but the addon ecosystem is oriented around coupled, Laravel-rendered sites. Validate before designing around it.
• You require contractual support. Small-maintainer addons rarely come with SLAs. For a revenue-critical surface, that gap is a buy-vs-build factor, not a footnote.
• The capability is a differentiator. If it's core to your product's value, own the code.
• You're not prepared to run a major upgrade. If there's no owner for dependency maintenance this quarter, deferring adoption is the honest call — but record it as a deliberate deferral with a review date.

How to Pitch It (Stakeholders)

To executives (one paragraph): This package extends our Laravel/Statamic content platform with functionality we would otherwise build and maintain ourselves. The new v2.0.0 release aligns it with Statamic 5 — the current major version of the CMS we run on. That's good for longevity and security, and it does mean a coordinated upgrade rather than an isolated dependency bump. The work is bounded and schedulable: bump the CMS and this addon together, test in staging, ship. The alternative — staying on the older line — is viable short term but moves us toward an unsupported branch.

To engineering (the ask): Treat v2.0.0 as a breaking change and plan accordingly. Confirm the platform constraints in composer.json, pin the version in composer.lock, and schedule the Statamic 5 upgrade as one unit of work with this addon. Check the changelog for any config or API surface changes beyond the version requirement, and flag anything that touches stored content — a data migration is the one item that can turn a one-day task into a two-week one.

Decision framing for the roadmap review: This is not a "should we adopt a new tool" question. It's a maintenance-and-timing question on a dependency we already rely on. The recommendation is to sequence the Statamic 5 upgrade deliberately — pick the date, staff it, and verify v1.x support status only if we choose to defer.