Page Blocks Laravel Package

Product Decisions This Supports

• Build vs. buy for in-app content editing. The recurring request in Laravel/Filament products is "let marketing edit the landing pages without a deploy." This package is a candidate to satisfy that without buying a headless CMS (Contentful, Sanity, Storyblok) or standing up Statamic alongside your app. The decision it informs is whether block-based page composition is a weekend integration or a multi-sprint build.
• Roadmap sequencing for CMS-adjacent features. If your roadmap has a "page builder," "editable marketing pages," "dynamic landing pages," or "template composer" epic, this sets the floor for scope: a block registry plus a Filament editing surface, rather than a full CMS with workflow, revisions, and localization. It lets you ship the 20% of CMS capability that covers 80% of the ask and defer the rest.
• Feature-level scoping: composer vs. CMS. A package like this draws a clean line between page composition (blocks, ordering, per-page layout) and content operations (revisions, scheduling, approval workflows, multi-site, translation). Use it to force the "do we actually need a CMS, or just a page composer?" conversation before anyone commits budget to the larger thing.
• Use cases it plausibly unlocks: marketing/landing pages inside an existing Filament admin, editable static pages (about, pricing, legal) that currently live in Blade, reusable content sections across tenants, email or notification template bodies, and internal tooling where non-engineers need to assemble structured content.
• Fork/absorb decision. MIT licensing with zero dependents means the realistic path for most teams is "vendor it, extend it, own it." That's a legitimate product decision — it converts a buy into a cheap build with a head start — and it should be priced against the cost of writing the block schema and Filament form components yourself.
• Reversibility assessment. Because the integration surface should be small (a JSON column, a block registry, a renderer), this is a low-regret decision. That matters when you're deciding whether to spike now for a Q3 launch or wait for a larger platform bet.

When to Consider This Package

Consider it when:

• You are already on Laravel + Filament and the editor would live in your existing admin panel. The value proposition collapses if you're not on Filament.
• You need block-based composition of a small number of page types — a handful of blocks, one or two content models — not a generalized layout engine.
• Your team is comfortable reading and extending PHP package source, and you're willing to pin the version and treat it as vendored code.
• You can absorb the maintenance if upstream goes quiet: fork it, add tests, own the upgrade path across Filament majors.
• You need something now for a prototype, internal tool, or an MVP where the cost of replacement later is bounded.

Look elsewhere — or budget to build — when:

• Adoption signal matters. Zero stars and zero dependents means no community has stress-tested it, no security researcher has looked at it, and no third party has documented the sharp edges. For a customer-facing surface, that's a real diligence gap. Verify test coverage, release cadence, and issue responsiveness before betting a launch on it.
• You need CMS-grade capabilities: revisions and rollback, scheduled publishing, editorial approval, localization/translation workflows, multi-site or multi-tenant content, preview environments, or granular permissions on content.
• You need a large or opinionated block library with accessibility, responsive image handling, and design-system integration baked in — you'll be authoring those blocks yourself either way.
• You need vendor support, SLAs, or a procurement-friendly dependency (regulated industries, security review boards).
• Filament's native Builder field already covers you. It handles repeatable, schema-defined block sets out of the box. If your need is "ordered list of typed blocks in a form," the honest answer may be zero dependencies rather than one more package. Run that comparison first — it's the cheapest possible outcome.
• You're on a Filament version this hasn't been validated against. Confirm compatibility explicitly rather than inferring it from the release date.

Diligence checklist before adoption: read the source end-to-end (it should be small enough to do so in an hour), confirm Filament/Laravel version constraints, check whether rendering is bundled or frontend-agnostic, verify how block data is persisted and migrated, check for XSS handling in rendered HTML, and confirm the license and attribution requirements.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed building block that lets non-engineers compose pages inside our existing admin panel, removing engineering from the loop for routine marketing and content changes. Cost is effectively zero in license fees and low in integration effort — the realistic commitment is a short spike plus a small amount of engineering ownership, not a platform migration. It is a candidate to replace either an expensive CMS subscription or a multi-sprint internal build. The caveat is maturity: it has no meaningful adoption yet, so we should treat it as code we adopt and own rather than a vendor relationship we depend on. That keeps the downside bounded — worst case we fork it or replace it, and the integration surface is small enough that neither is expensive.

To engineering: It fits our existing Laravel/Filament stack and should be a thin dependency: a block registry, a Filament editing surface, and persisted block data. The proposal is to spike it against our real page requirements, read the source, pin the version, and wrap it behind our own rendering abstraction so the package is swappable. The explicit trade-off is that we take on ownership — expect to fork, add test coverage, and carry Filament major upgrades ourselves. If the spike shows it's a thin wrapper over Filament's native Builder field, we ship the native field instead and skip the dependency entirely.