Filament Page Builder Laravel Package

Product Decisions This Supports

• Build vs. buy for content editing: Replaces the "we'll just build a simple CMS" ticket that routinely balloons into months. If your marketing pages, landing pages, or CMS-lite sections live in a Laravel app that already runs Filament, this is a candidate to short-circuit a custom page-composition build.
• Self-serve content operations: A visual, block-based editor inside the admin panel shifts page edits from engineering to marketing/content. That directly reduces the "one-line copy change" ticket load and shortens the content release cycle from sprint cadence to same-day.
• Roadmap sequencing: Useful as a de-risking spike before committing roadmap capacity to a bespoke page builder. One sprint of evaluation tells you whether block-based composition meets your editors' needs or whether you genuinely need structured content modeling, workflows, and localization.
• Feature scoping for admin UX: If your product already exposes Filament to internal or client users, this package defines a pattern (register a set of blocks, compose them per page, render through your own Blade views) you can either adopt wholesale or borrow selectively. It clarifies what "good enough" page composition looks like versus a full CMS.
• Use cases worth validating: marketing/landing pages, CMS-style static pages, help-center or docs sections, tenant-specific site pages in a multi-tenant app, and internal communications pages. All are cases where the page structure is simple, the audience is small, and the cost of a heavyweight CMS is hard to justify.
• Risk/exit decision: Because content is typically serialized (block config rather than free-form HTML), you retain an escape hatch — your own render components and templates — which keeps switching costs low if you outgrow the package.

When to Consider This Package

Consider it when:

• You are already on Laravel + Filament and the content lives in the same app/admin as the rest of your operations. The integration cost is the main reason to pick it over a standalone CMS.
• Your editors need to compose pages from a fixed library of blocks (hero, rich text, CTA, gallery, etc.) rather than free-form WYSIWYG or fully arbitrary layouts.
• Your team is small and engineering-constrained, and the alternative is building and maintaining a page builder in-house.
• The pages are low-to-medium complexity and low-risk — marketing pages, not regulated or transactional content.
• You can own the render layer — i.e., you're comfortable writing and maintaining the Blade components that turn serialized block data into markup.
• You treat this as an evaluation-stage dependency: you can pin a version, review the source (MIT), and fork if needed.

Look elsewhere when:

• Maturity matters. 55 stars, a single maintainer, and a last release in September 2024 signal a young, low-bus factor project. Do not put this on a revenue-critical path without a fork-and-own plan.
• You need structured content modeling, editorial workflow, scheduled publishing, granular roles, or localization pipelines. These are CMS-class requirements and are typically outside the scope of a block-based page builder.
• You are not on Filament, or your admin is a different stack — you'd be adopting the framework to adopt the package.
• You need guaranteed long-term support, SLAs, or a vendor — this is community OSS.
• Your editors need pixel-level design control or arbitrary HTML/CSS; a constrained block library will frustrate them, and you'd be re-implementing a design tool.
• Pages are high-traffic or SEO-critical at scale and you need caching, CDN, and rendering strategies the package does not own.

How to Pitch It (Stakeholders)

For executives: We have a recurring cost — every marketing or content page change routes through engineering. This package is a low-cost, MIT-licensed option to give content owners a visual editor inside our existing admin, so simple page changes stop consuming engineering sprints. The trade-off is maturity: it's a small, single-maintainer open-source project, so I recommend a time-boxed evaluation and a clear plan to own the rendering layer ourselves before we commit beyond a pilot.

For engineering: It's a Filament-native visual page builder — blocks registered in code, page composition stored as structured data, rendered through our own Blade views. That last point is the important one: the package handles the editing UX, we keep control of output, which bounds lock-in. The codebase is small and MIT, so auditing and forking are realistic. Adoption cost is low if we're already on Filament; the risk is maintenance burden and API churn on a young project. Proposed approach: two-week spike, pin the version, build two or three real pages, and write down our fork-or-replace criteria before we put it in front of real editors.

For content/marketing stakeholders: This would let you edit and publish page content directly, without waiting for a developer, using a library of pre-approved blocks so pages stay on-brand and consistent. We'd start with a small pilot on a few pages to confirm it fits how you actually work before rolling it out.