Filament Page Builder Laravel Package

Product Decisions This Supports

• Build vs. buy for content editing. The package answers a narrow, recurring build-vs-buy question: do we hand-roll a block editor for our Filament admin, integrate a headless CMS, or drop in a package? For "CMS-lite" needs it collapses weeks of bespoke block-picker, reordering, and form work into a dependency.
• Data model shape for page content. Storing ordered, typed blocks in a single JSON column is the real architectural decision here, and it's a cheap one: no migration per block type, easy to snapshot, easy to roll back. The tradeoff we're accepting is that content becomes hard to query by field, index, or join — fine for rendered pages, painful for reporting or content search.
• Feature scoping on the roadmap. This lets us say "page composition is a solved, configurable surface" and keep team capacity on differentiators. It also gives us a defensible reason to defer revision history, scheduled publishing, multi-locale content, and editorial workflows in v1 rather than silently omit them.
• Concrete use cases it unblocks: marketing/landing pages, help and docs pages, tenant- or client-editable sections inside an existing admin panel, internal announcements — anywhere a non-technical editor needs layout control and we already run Filament.
• Upgrade sequencing. Explicit support across Filament 3, 4, and 5 (with version-pinned branches) means an admin-panel upgrade doesn't force a content-editor rewrite, which is a real line item in our platform-maintenance budget.
• Vendor-risk triage. 14 stars, 0 dependents, single maintainer, MIT. That's a decision input, not a disqualifier — but it should route through a "pin, wrap, and plan to fork" posture rather than an unexamined dependency.

When to Consider This Package

Adopt when:

• We're already on Filament 3/4/5 with PHP 8.3+, and the content editing lives inside that admin panel — not a separate CMS.
• Editors are internal staff or trusted tenants, not an anonymous public authoring base.
• We render pages ourselves (Blade/Livewire components per block type), so the package supplies the editing UX and storage contract, not the presentation.
• Block types are a bounded set — roughly under 15 — and stable enough that we won't be rewriting JSON content monthly.
• No hard requirements for per-field querying, revision history, per-block permissions, multi-locale content, or scheduled publishing.

Look elsewhere when:

• We need a real CMS: editorial workflows, approvals, revisions, previews, i18n, A/B testing, or content APIs for multiple consumers.
• Content must be queried, filtered, or reported on by field — normalized tables beat a JSON blob every time.
• The public site is SEO- or performance-critical and page rendering/personalization is a first-class concern.
• We need vendor support, an SLA, or a maintainer with a track record — one maintainer and 14 stars is a bus-factor of one.
• We're not on Filament, or we're on a Filament version outside the supported matrix.
• The block schema is genuinely volatile; we'd be building and owning JSON migration tooling ourselves, which erases the buy-side savings.

Adoption guardrails I'd attach: pin the exact version, keep our block renderer behind our own interface so the package is swappable, version the block schema inside the JSON, and budget a fork contingency (MIT makes this viable).

How to Pitch It (Stakeholders)

For executives — the short version: This is a small, MIT-licensed drag-and-drop page editor for the admin framework we already use. It lets non-technical staff compose and reorder page content without engineering involvement, for roughly the cost of an integration rather than a build. It adds no new service, no new database table, and no licensing fee — content lands in one JSON column on an existing model. Expected effort is days, not a quarter. The risk is supply-side, not technical: it's a young package with one maintainer, so we treat it as a pinned dependency with a fork fallback rather than a strategic platform bet. Recommendation: pilot it on one low-risk content surface, measure editor adoption and support load for a release cycle, then decide whether to standardize.

For engineering — the practical framing: Filament-native, PHP 8.3+, supports Filament 3/4/5 with versioned branches, stores ordered typed blocks in a single JSON column, MIT. Integration is a form component plus our own renderers per block type. The constraints we're knowingly accepting: content isn't queryable by field, schema migrations are ours to write, and Filament major upgrades put us at the mercy of the maintainer's release cadence. Mitigations: pin, wrap the renderer, version the block schema, keep a fork path open.

The ask: approve a scoped pilot (one surface, one release cycle) with a decision gate on editor adoption, maintenance burden, and whether we hit any JSON-query limits that would force normalization.