Buildamic Laravel Package

Technical Evaluation

Architecture fit. Buildamic is a Statamic 3 addon, which in Laravel terms means a standard package: a service provider registered via auto-discovery, publishable config/views/assets, and a custom fieldtype (Vue in the control panel, Blade/Antlers on the front end). It introduces no new runtime, no database schema, and no external service. For a project already on Statamic 3, it slots into the existing content architecture rather than sitting beside it. The critical architectural property is that it is a content-model package: page composition is persisted as structured data inside your flat-file content tree, so Buildamic's section/set schema becomes part of your content contract, not just a rendering concern.

Integration feasibility. Mechanically low-effort: composer require handmadeweb/buildamic, publish the config, declare your "sets" (section types), map each to a Blade partial, and attach the Buildamic field to the relevant blueprints. A single page can be proven out in a day. The gating question is not effort but version compatibility.

Technical risk. This is a high-risk dependency for a low-traffic package. Eleven stars and zero dependents means effectively no peer-validation: you will not find a body of public experience describing upgrade breakage. It is agency-maintained (Handmade Web), so release cadence is tied to their own client work. Statamic 3 is now several major versions behind, and Statamic addon compatibility is version-locked at the Composer constraint level — the package may simply refuse to install, or install and fail subtly, on Statamic 4/5. The MIT license means forking is legally clean, but a fork converts a dependency decision into an owned codebase decision. Secondary risk: content lock-in. Once editors have authored pages through the builder, the stored shape is Buildamic's shape, and moving to native Replicator/Bard or another builder is a per-entry data migration, not a config swap.

Key questions to resolve before commitment.

• What is the exact statamic/cms constraint in composer.json, and does it admit our target Statamic version?
• Is there a tagged release matching current HEAD, and what is the commit history over the last 12 months?
• Does the fieldtype's stored payload survive a Statamic major upgrade without transformation?
• Who owns the addon if Handmade Web deprioritises it — do we have appetite to maintain a fork?
• Does it cover our editor requirements (nesting depth, reusable sections, previews), or are we adopting it and then extending it?

Integration Approach

Stack fit. Good, conditionally. It assumes a conventional Statamic 3 project: Composer, Blueprints/Fieldsets, Antlers or Blade templates, and the standard control panel asset pipeline. It does not want a headless split or a separate admin SPA, so it fits a monolith-style Statamic site and fits poorly if we are serving content to a decoupled front end — the builder's output is a server-side render, and exposing the raw structure via API pushes the rendering contract onto consumers.

Migration path. Two distinct paths, and they should not be conflated:

• Greenfield on Statamic 3 — the clean case. Adopt at project start, before content exists, so the content-shape commitment carries no backfill cost.
• Existing site or Statamic 4/5 — not a migration, a fork-and-port. Budget for constraint widening, CP asset rebuild, and a full pass over the fieldtype's save/load behaviour. Treat this as weeks, not hours, and confirm there is no upstream intent to support the newer version first.

The exit path matters as much as the entry path: define the canonical page data shape we would want without Buildamic, and verify the stored payload can be transformed into it mechanically. If it cannot, the lock-in is worse than it looks.

Compatibility. Pin the addon version explicitly and pin statamic/cms alongside it. Two unconstrained dependencies in this relationship guarantee a surprise. Verify PHP version support against our runtime, and check whether the CP assets ship prebuilt or require a Node build step in our pipeline.

Sequencing. (1) Compatibility spike: install on a throwaway Statamic 3 instance, confirm install and CP render. (2) Vertical slice: one representative page type, one developer, one editor, end to end in Blade. (3) Editor evaluation: two or three real page compositions, judged on authoring speed and structural clarity — this is the only part of the assessment that cannot be done by reading code. (4) Decision gate: proceed, fork, or fall back to native Replicator/Bard. Do not run this in parallel with other content-model decisions; it constrains them.

Operational Impact

Maintenance. The realistic assumption is that we own maintenance. Upstream is a small agency addon with a small audience; expecting timely releases for our Statamic version is optimistic. That means a named internal owner, a fork on our VCS, and a policy that the fork is rebased at each Statamic upgrade. If nobody will accept that ownership, the answer is no regardless of how well the demo looks.

Support. No vendor SLA, no commercial support tier, issues handled on a public tracker at whatever priority the maintainer assigns. Acceptable for an internal authoring tool where a bug is an inconvenience; less acceptable if the page builder is on the critical path for a client-facing marketing site with a content team working daily. Editors encountering a broken fieldtype on a deadline is the scenario to price in.

Scaling. Flat-file content means no database contention; the cost centre is render time. Deeply nested builder structures compound partial renders per page, and that multiplies across listings and large navigation surfaces. Statamic's static caching resolves this for public traffic, but the control panel remains uncached — pages with very large builder payloads will feel slow to editors long before they affect visitors.

Failure modes. Ranked by likelihood and blast radius:

1. Statamic upgrade breaks the addon — high likelihood, blocks all upgrades until forked.
2. Abandonment — no upstream fix, we inherit the code.
3. Stored data shape divergence — silent, only surfaces when rendering or exporting.
4. CP asset/build breakage on deploy — editor-facing outage, quick to fix but disruptive.
5. Fork drift — the rebase stops happening and the fork quietly becomes its own product.

Ramp-up. Developers need working Statamic and Antlers/Blade fluency; Buildamic adds roughly a day on top of that. The larger cost is editorial: a page builder is a new authoring mental model, and the "sets" taxonomy we define becomes the thing editors live inside. Budget for a short training pass, a written set glossary, and a rule that the available sets stay deliberately small. Page builders fail operationally when the set library grows faster than it is curated — that is a governance commitment we take on by adopting this, independent of the package's quality.