Buildamic Laravel Package

Product Decisions This Supports

• Build vs. buy vs. assemble for the authoring experience. Buildamic is a block-based page composer layered on Statamic 3, so it sits directly in the "do we build our own page builder, buy a SaaS one, or assemble open-source pieces" decision. It is a concrete option that avoids a six-figure custom editor build.
• CMS platform standardization. Choosing this effectively means committing to Statamic 3 (Laravel/flat-file) as the content backbone. That ripples into hosting, content modeling, deploy workflow, and how content moves between environments — a platform-level call, not a plugin-level one.
• Roadmap sequencing for martech/editorial tooling. If marketing-page velocity is a bottleneck (dev tickets for every landing page), this is a candidate to close that gap before investing in a headless CMS migration or a commercial visual editor.
• Feature scoping: how much editing freedom do content teams actually need? Buildamic's block model forces an explicit decision about which components are marketer-editable, which are locked, and where brand/design governance lives.
• Vendor-risk and maintenance budgeting. MIT licensing with 11 stars and a single maintainer means the real product decision is "adopt as a dependency" vs. "adopt as a fork we own." That determines whether you budget engineering maintenance hours into the roadmap.
• Prioritizing which surfaces get the investment. Useful for deciding whether page-composition tooling beats other backlog items (localization, DAM, personalization) for the same engineering capacity.

When to Consider This Package

Consider it when:

• You are already on Statamic 3 and the native Bard fieldset/sets approach is too rigid for how your marketing team composes pages.
• You need structured, reusable block components rather than freeform WYSIWYG, and you want that without a SaaS page-builder contract.
• Your team has PHP/Laravel capacity to read, patch, and if necessary fork an MIT addon — treat the fork cost as part of the TCO.
• The scope is internal or mid-traffic marketing/content sites where a bespoke editor is overkill and enterprise SLAs are unnecessary.
• You want a fast pilot to validate whether block-based authoring actually improves publishing velocity before committing to a bigger platform bet.

Look elsewhere when:

• You are on Statamic 4/5 or plan to upgrade — pinning to a Statamic 3-era addon with low activity creates an upgrade cliff.
• You require vendor support, SLAs, security response commitments, or long-term maintenance guarantees — this is a community project with a very small footprint (11 stars), which is the single biggest adoption risk.
• Native Bard + sets/partials already meets your needs — the cheapest page builder is the one you don't add.
• You need enterprise-grade capabilities: localization workflows, approvals, personalization, A/B testing, asset governance, or a content API for multiple channels. Commercial options (Storyblok, Builder.io, Contentful + composition layer) cover these out of the box.
• Your content team is non-technical and needs hand-holding — small-community addons rarely come with the docs, onboarding, or support responsiveness a marketing org expects.

How to Pitch It (Stakeholders)

For executives: Buildamic is an MIT-licensed page-builder addon for Statamic 3 that lets marketing compose pages from pre-approved blocks instead of filing dev tickets for every landing page. The strategic upside is publishing velocity and reduced engineering drag on routine content work, at near-zero license cost. The caveat is maturity: a small community and a single-maintainer profile mean we should fund it as a time-boxed pilot with an explicit exit plan, not as a platform commitment. Recommended framing: approve a scoped pilot with a fixed engineering budget for hardening/forking, and gate broader rollout on measured reduction in dev tickets per page and on a documented path for Statamic 3 → 4/5 (either our own upgrade work or a migration off).

For engineering: This is a Laravel/Statamic addon — low integration cost if we're already on Statamic 3, and MIT means we can vendor and patch it. The ask is that we own the dependency: audit the code, pin versions, and decide up front whether we maintain upstream or carry a fork. It should not become an unowned transitive dependency in the critical content path.