Statamic Button Box Laravel Package

Product Decisions This Supports

• Editor experience vs. feature scope: A fieldtype-level addon that turns a set of predefined choices into styled buttons in the Statamic control panel. It lets you ship "client-friendly" configuration (layout variants, CTA styles, section themes, plan tiers) without spending sprint capacity on custom Vue components in the CP.
• Build vs. buy for CP polish: Typical in-house cost for a bespoke fieldtype is one to three days of engineering plus ongoing Statamic-upgrade maintenance. At a 2-star, 0-dependent footprint, the honest comparison is "adopt in an afternoon and own the risk" versus "build a 40-line custom fieldtype we fully control."
• Roadmap triage: The low opportunity score (~31) confirms this is a tactical UX addon, not a platform bet. It belongs in the "quality-of-life backlog" bucket for client projects, not in a core product differentiator discussion.
• Onboarding and support-cost reduction: Constrained choice UIs measurably cut "which option do I pick?" tickets from non-technical editors. If your support load is dominated by content-entry confusion, small fieldtype investments are the cheapest lever available.
• Data portability is a non-issue: Choice values are stored as plain content, so adopting or removing the addon is a presentation-layer change, not a migration. That lowers the stakes of the decision considerably — this is reversible.
• Not a fit for: anything needing image thumbnails, searchable long option lists, or multi-select semantics. Those want a dedicated visual-picker fieldtype, and stretching this one will cost more than it saves.

When to Consider This Package

Adopt when:

• You are already on Statamic (this is not a general Laravel package) and the project runs a version the addon supports — verify the compatibility matrix against your Statamic major before committing.
• Fields have a small, stable option set (roughly 2–6 choices) where the label alone communicates the outcome. Buttons shine for "Compact / Comfortable / Spacious," not for a 40-item taxonomy.
• The audience is non-technical client editors and CP clarity is an explicit acceptance criterion in the project.
• The addon is used in a bounded way — one or two fields per site — so that if it goes unmaintained, replacement is a scoped afternoon rather than a refactor.

Look elsewhere when:

• Bus factor is a blocker. One maintainer, 2 stars, 0 dependents, no downstream usage to catch regressions. For a multi-year enterprise build with a formal dependency policy, this fails even a light procurement review. For an agency site with a 12-month horizon, it is fine.
• You need multi-select, search, or image-based options.
• Accessibility requirements are strict and you cannot audit the rendered control — confirm it degrades to real form inputs with keyboard and screen-reader support before shipping to a public-sector or regulated client.
• Your team's Statamic version is ahead of the last release (2026-03-02). Recent publication is a good signal of activity, but pin the version and re-test on each Statamic upgrade.
• The same outcome is achievable with Statamic's built-in radio/select field plus CSS. If a styled select passes the client demo, skip the dependency entirely.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost addon that makes the content editing screens look and feel deliberate for our clients. It converts abstract settings into obvious visual choices, which reduces the back-and-forth that eats into account management time on every site we hand over. Cost is effectively zero and it is fully reversible — content is stored the same way either way, so if we stop using it, nothing breaks and nothing needs migrating. It is a polish item, not a strategic investment, and should be scoped accordingly.

To engineering: A Statamic fieldtype addon from a known name in the Statamic community. Narrow surface area: it overrides how a choice field renders, not how data is stored. Risks are the usual ones for a single-maintainer, low-adoption package — pin the version, use it in one or two fields per project, and re-verify on each Statamic major upgrade. The real decision is whether a half-day adoption beats a one-to-three-day in-house fieldtype we own outright. Recommendation: pilot it on one client build, measure editor support tickets before and after, and treat in-house replacement as the fallback rather than the default.