Filament Atelier Laravel Package

Product Decisions This Supports

• Build vs. buy for a marketing/CMS surface. The recurring PM question is whether to ship a page builder as a roadmap line item (~1–2 engineer-quarters for editor, block schema, preview, publishing, SEO) or adopt one. Atelier is a credible "buy" candidate if you are already a Filament panel shop: the editor, block picker, draft/publish split, per-locale SEO, sitemap and JSON-LD are the parts you'd otherwise under-scope.
• Client self-service scope. The code-defined block model sets a clear contract: developers own the catalogue of section types, clients own composition and copy. That is a product decision you can defend to a stakeholder — it bounds blast radius (no raw HTML block, no client-authored layouts) while still removing the "can you change the headline" ticket queue. Note the deliberate gap: no header/footer/contact-form/raw-HTML blocks, so plan who owns those.
• Multi-language and RTL as a feature bet. Per-locale slugs, lang/dir, hreflang, per-locale SEO and noindex, with RTL font stack following dir not locale code, is unusually complete for a package this young. If internationalisation is on the roadmap, this converts a hard build into a config decision — and it derisks the RTL work most teams underestimate.
• SEO as a launch gate, not a phase two. Sitemap generation with lastmod and alternates, per-page noindex dropping pages from the sitemap, 301s on published slug renames, and a single JSON-LD graph with typed page schemas (nine types, FAQ from a block) are the items that typically surface late and slip launches. Having them native changes the launch checklist.
• Extensibility surface to price. ->sitemap([...]) closures and @include("atelier::partials.schema") mean non-Atelier routes (blog, services) share the same organisation graph and sitemap rather than drifting. That's a real integration cost avoided — worth weighing in a build estimate.
• Rendering strategy decision. JSON tree of typed blocks rendered server-side by Blade — no HTML in the database, no block validation chains, no per-request page cache needed at MVP scale. This is the "boring and fast" option versus headless CMS + JS renderer; it also means content is portable (JSON) and the public site stays in a stack your team can debug.
• Design-token ownership. Colour/type/spacing/width as CSS custom properties read by both editor preview and public page means the preview can't drift from production. That directly reduces the most common client complaint about builders ("it doesn't look like the preview") and reduces QA cycles per page.

When to Consider This Package

Consider it when most of these are true:

• You are on Laravel 12/13 + Filament 5 + Livewire 4 + Tailwind 4 already. Retro-fitting Filament for this alone is not a saving.
• The site is content-marketing shaped — landing pages, service pages, about/FAQ, multi-locale — not app UI or user-generated layouts.
• You accept developer-authored blocks as a feature, not a limitation. Your delivery model includes an engineer adding section types as the design system grows.
• You need per-locale content and SEO with real RTL support, and would otherwise build it.
• You can absorb MVP maturity: read the "Not built yet" list and the "known limits" wiki page before committing to a client.
• You can live with up/down button reordering, sections appended at the end, and no revisions browsing UI (restoreRevision() exists; the screen doesn't).
• You have an exit plan: content is JSON; rendering is Blade views you control; the licence is MIT. Migration out is a data transform plus your own renderer, not a rewrite of stored HTML.

Look elsewhere when:

• Bus factor and adoption signals are the deciding factor. 34 stars, 0 dependents, a single maintainer, and a first release in September 2026 is pre-traction. If procurement requires community maturity or a support contract, this fails the test today.
• Clients must create block types from the panel. That is explicitly v2 and parked. If your product promise is "clients invent their own sections," this is the wrong model.
• Non-technical stakeholders need to go live without a developer. No header/footer/contact-form blocks, no raw HTML, no drag-reorder. Each gap becomes your ticket.
• You need measured performance guarantees. No per-block asset loading, no page cache, no recorded Lighthouse budget. If Core Web Vitals SLAs are contractual, you own that work.
• You are not on Filament. The whole editor is a Filament plugin; the value is contingent.
• You need form handling built in. The contact form is presentational by design, posting to a route you wire.

How to Pitch It (Stakeholders)

For executives — one paragraph. Atelier gives us a client-facing page builder without us building one: a full-screen editor with a true-to-production live preview, draft/publish separation so edits never touch the live site, per-language content and SEO, sitemap, redirects and structured data out of the box. Engineering defines the section library in code; the client composes pages from it. That keeps quality and brand consistency under our control while removing routine content tickets. It's MIT-licensed, has no page-builder dependency to inherit, and pages render as server-side Blade, so speed and SEO aren't traded away for editability. The honest caveat: it is a solo-maintained MVP — 34 stars, no downstream dependents, first release this month, and a published list of what isn't built (no header/footer blocks, no drag-reorder, no revisions screen). Recommendation: pilot on one internal or low-risk marketing site, budget one engineer for block authoring and gap-filling, and re-evaluate before making it the standard for client delivery.

For engineering — the technical case. A page is a JSON tree of typed blocks rendered by Blade at request time: Gutenberg's data model with Elementor's rendering approach, minus stored HTML and block validation chains. A block is one PHP class declaring key/label/icon/category plus a Filament schema, and one Blade view — registered via AtelierPlugin::make()->blocks(...) and it appears in the picker; no plugin internals are edited. supports() gives background and vertical spacing to every block for free. Design tokens are shared CSS custom properties between the editor preview and the public layout, so preview and production cannot drift. Publishing writes revision snapshots with restoreRevision(); preview links are signed and expiring; slug changes write 301s. The JSON-LD graph is built at render from data already entered (no second copy, no cache to clear) and can be extended into your own routes via atelier::partials.schema, with ->sitemap() accepting closures or invokable classes. Watch the operational detail: new tables ship as new migration files, so re-publish and migrate on every upgrade — skipping it surfaces as a "no such table" error at first use. Also point Tailwind at the package views; the install guide calls out three steps that fail silently if missed.