Statamic Focal Point Fieldtype Laravel Package

Product Decisions This Supports

• Build vs. buy (or build vs. adopt): A Laravel/PHP package is a buy-side decision measured in engineering weeks, not license cost. The PM question is whether the capability is a differentiator worth owning or commodity plumbing better delegated to a maintained dependency.
• Roadmap sequencing: Adoption compresses the time between "we need this capability" and "we can ship the user-facing feature," freeing sprint capacity for work customers actually notice.
• Scope discipline: Packages define a boundary — what the team configures versus what it maintains. That boundary is a roadmap commitment as much as a technical one, because every adopted dependency adds upgrade work to future quarters.
• Platform standardization: Standardizing on a well-maintained package across services reduces divergent in-house implementations of the same problem, which lowers onboarding cost and incident surface area.
• Risk and compliance posture: Dependency health (release cadence, security response, maintenance continuity) is a product risk input, particularly for anything touching auth, billing, or data handling.
• Use cases this class of package typically serves: authentication/authorization, payments and subscriptions, admin and operations tooling, media handling, search, notifications, audit logging, integrations with third-party APIs, and internal scaffolding that is not customer-visible.

When to Consider This Package

Consider adoption when most of the following hold:

• The capability is undifferentiated. It is infrastructure the product needs but customers will not choose you for.
• The maintenance signal is healthy. Recent releases, responsive issue triage, a documented upgrade path, and evidence of use beyond a single author. A Laravel package with an empty release history and no visible maintainer activity is a warning, not a green light.
• It fits the framework's grain. First-party conventions, service-provider registration, configuration publishing, and no fighting the container or the ORM. Packages that bypass Laravel idioms create permanent friction.
• The upgrade cost is bounded. Major-version cadence is predictable and the changelog distinguishes breaking from additive changes.
• The exit is survivable. Data lives in your schema, the public API surface is narrow enough to wrap, and replacing it later is a contained project rather than a rewrite.
• The team can own it. At least one engineer can read the source when behavior is surprising. Adopting a package nobody on the team can debug is a bet on the maintainer's availability.

Look elsewhere when:

• The capability is core to your differentiation or your security boundary.
• The package is abandoned, single-maintainer with no succession signal, or has unresolved security advisories.
• Requirements are unusual enough that you would be fighting configuration defaults more than writing code.
• It pulls in a heavy transitive dependency tree for a narrow slice of functionality.
• Licensing or data-handling terms conflict with your compliance obligations.

How to Pitch It (Stakeholders)

For executives: This is a build-versus-adopt call on commodity functionality. Adopting a maintained Laravel package converts a multi-week engineering project into a configuration task, and it shifts ongoing cost from our team's maintenance budget to an external maintainer's. The decision hinges on dependency health, not features — so the ask is a small evaluation window, not a large commitment.

For engineering: The proposal is to adopt rather than reimplement, with three conditions: we wrap the package behind our own interface so it is replaceable, we pin versions and treat major upgrades as scheduled roadmap work rather than surprises, and we verify the maintainer's release cadence and security posture before we depend on it. If any of those conditions fail, we build the narrow slice we actually need.

Decision requested: Approval to evaluate and, if the health criteria hold, adopt — with a named owner responsible for upgrade cadence and a documented rollback path.