Product Decisions This Supports
- Build vs. buy for addon configuration UX. Forma answers a recurring question for any team shipping Statamic addons: do we hand-roll a Control Panel settings screen (routes, views, validation, persistence) for every addon, or adopt a shared form-builder abstraction? It lets you standardize that layer instead of rebuilding it per addon.
- Addon portfolio strategy. If you maintain or plan multiple Statamic addons, Forma supports a "consistent settings experience across the suite" decision — one configuration paradigm, one mental model for customers, one code path to maintain.
- Roadmap and time-to-market. Time spent on settings plumbing is time not spent on differentiating features. Adopting Forma is a bet that configuration UI is commodity work worth delegating, freeing roadmap capacity for the capabilities customers actually pay for.
- Commercial packaging. For paid addons, a polished, predictable CP configuration page is a visible quality signal. Forma makes "looks and feels first-party" a cheap default rather than a bespoke investment per product.
- Support and onboarding cost. A shared configuration pattern reduces bespoke docs, reduces "where do I set X?" tickets, and makes new addons easier to hand off between engineers.
- Use-case fit. Best suited to structured settings (toggles, text, selects, validation, saved config) inside Statamic's CP. It is not a decision lever for customer-facing UI or complex interactive workflows.
- Dependency posture. With low adoption signals (small star count, zero dependents) and a single-maintainer profile, adopting Forma is really a decision to accept a tolerable, isolatable dependency rather than a strategic platform commitment — which is appropriate only if it is wrapped or vendored.
When to Consider This Package
Consider it when:
- You are building Statamic addons and need Control Panel configuration/settings pages, not just config files.
- Your settings needs are conventional — field types, validation, persistence, sensible defaults — rather than highly custom interactive UI.
- You want consistency across several addons and prefer a shared, opinionated pattern over bespoke views per package.
- You have engineering capacity to read and own the integration, including the ability to vendor or fork under MIT if upstream stalls.
- You are comfortable with a thin, low-blast-radius dependency — it touches the admin configuration surface, not runtime customer traffic, so failure modes are contained and recoverable.
- You want to prototype quickly and validate addon demand before investing in a bespoke settings experience.
Look elsewhere when:
- You are not on Statamic, or your addon targets a Statamic version the package does not clearly support.
- You need rich, bespoke or highly interactive configuration UI (custom JS components, complex conditional workflows, live previews) that a form abstraction would fight against.
- You require vendor SLAs, security guarantees, or long-term maintenance commitments. A single-maintainer, low-adoption package cannot supply these; treat it as community code you may need to own.
- The addon is customer-facing or commercially critical and configuration is part of the paid value proposition — in that case, owning the UI layer may be the differentiator rather than a cost to avoid.
- You ship exactly one addon with trivial settings; the abstraction may cost more than a small hand-written page.
- Your procurement or dependency policy flags low-adoption packages (few stars, zero dependents) without an explicit internal owner and exit plan.
Adoption guidance: pilot on one internal or non-critical addon, time-box the evaluation, and put a thin internal wrapper around Forma so the rest of your codebase is not coupled directly to it. Reassess on the next major Statamic release.
How to Pitch It (Stakeholders)
For executives: Forma is a free, MIT-licensed building block for our Statamic addons. It gives every addon a consistent, professional-looking settings page in the admin Control Panel without us designing and building one each time. The business case is straightforward: it converts a repeated, undifferentiated engineering cost into a near-zero marginal cost, shortens addon delivery timelines, and makes our addon suite feel like one coherent product to customers. The cost is effectively zero in license terms and small in integration effort. The risk is dependency risk — it is a low-adoption, single-maintainer package — so we manage it the way we manage any small open-source dependency: wrap it, keep the option to fork, and do not let it become load-bearing for anything customer-critical without a review.
For engineering: Forma provides a fluent way to define addon configuration fields, validation, and persistence, rendered as a native Statamic CP page. That removes hand-rolled routes, views, and save logic from each addon and gives us one pattern to test and document. Integration is small and the surface area is contained to admin configuration, so the blast radius of a defect or an abandoned upstream is limited. We should adopt it behind a thin internal adapter, pilot it on one addon, confirm version compatibility, and pin the version. If upstream activity stops, MIT lets us vendor the code and continue — the exit cost is low, which is why the risk is acceptable.
Recommendation: Approve a scoped pilot on a single non-critical addon, with a written compatibility and ownership check before any wider rollout across the addon portfolio.