Statamic Bard Color Picker Laravel Package

Product Decisions This Supports

• Editorial velocity vs. design-review bottleneck. Today, when marketing wants a callout in a brand accent color, the path is usually "ask a developer to add a CSS class" or "ask design to approve a one-off." A swatch-restricted color picker inside Bard collapses that loop: editors pick from approved colors, ship the page, and design governance is encoded in the tool rather than enforced in meetings.
• Brand consistency as a product requirement. Because the addon constrains editors to a curated swatch palette (not a full color wheel), it converts "please follow the brand guide" from a training problem into a product constraint. That is a much cheaper control than audits or review gates.
• Build vs. buy on the Bard toolbar. The alternative is a custom ProseMirror mark + toolbar extension + config plumbing — roughly 1–3 engineering days plus ongoing ownership of a bespoke extension. At 11 stars and zero dependents this is not an ecosystem bet; it is a small, inspectable piece of code. The "buy" (install) side of the ledger wins unless your color requirements are unusual.
• Roadmap input for the content platform. If this earns a place in the stack, it opens a coherent next step: align swatches to design tokens (CSS custom properties / theme variables) so a rebrand updates content colors without a data migration. That is a platform-level conversation, not a feature request.
• Scoping signal for multi-brand or campaign work. Sites that need per-section or per-campaign accent colors can treat swatches as configuration per field, which keeps the CMS flexible without giving editors unbounded styling power.

When to Consider This Package

Adopt when all of the following hold:

• You are on Statamic and already using Bard as the rich-text fieldtype — this addon is worthless outside that context.
• Editors have a real, recurring need for inline text color (callouts, pricing emphasis, legal asides, campaign landing pages) that is currently routed through developers.
• Your color set is finite and brand-defined — a handful of approved swatches, not arbitrary color choice.
• You are comfortable with a small, single-vendor addon. At 11 stars and 0 dependents, you are effectively the first production user of consequence. Mitigate by pinning a version, reading the source (the surface is small), and being prepared to fork. The recent release date is a positive maintenance signal but not a guarantee.
• Your team can absorb the upgrade coupling between the addon, Statamic major versions, and Bard's editor internals.

Look elsewhere (or build in-house) when:

• You need background/highlight colors, font sizing, or full typography control — this is text color only.
• You want colors to derive automatically from CSS variables or design tokens rather than a hand-maintained swatch list.
• You require a vendor with an SLA, security review, or commercial support — this is an agency-published addon with no dependents to signal battle-testing.
• You are not on Statamic, or your editors use a different fieldtype (Markdown, Redactor, plain textarea).
• Your accessibility posture requires guaranteed contrast enforcement — a swatch picker limits but does not prevent unreadable combinations.

How to Pitch It (Stakeholders)

For executives (one paragraph): Content teams regularly need emphasis colors in articles and landing pages, and today that request becomes a developer ticket or a design review. This addon puts a curated, brand-approved color palette directly in the editor for a few hours of integration work, which removes a recurring handoff from the publishing path and keeps the brand guide enforced by the tool instead of by memory. The cost and risk are both small: it is a narrow addon on a stack we already run, and if it ever stops being maintained we can absorb the code ourselves.

For engineering: A Statamic Bard addon that registers a toolbar color control with a configured swatch set. Scope is deliberately narrow — a fieldtype/toolbar extension plus config, no database changes, no external services. Integration is an install, a config entry for the palette, and a styling pass so the swatch values map to our design tokens. Recommended posture: pin the version, read the source before merging (it is small), and keep the swatch list in config rather than in content so a rebrand is a config change, not a migration. Forking is a realistic fallback given the low adoption.

For design/brand: The palette becomes the single source of truth for allowed emphasis colors, which means fewer off-brand one-offs and a clean path to tying swatches to tokens later. Recommend we also publish contrast guidance alongside the swatches, since the picker constrains choice but does not evaluate readability.