Skip to main content
Capell home
Live demo

Choose Laravel-owned redesign decisions

Choose Blade, Livewire, Inertia, or Vue for the public presentation. Capell resolves approved content and page context; the project's components turn that data into the finished visitor response.

That boundary keeps a future redesign in the application codebase. If several independent channels need one hosted content API, a headless CMS may fit better than this coupled Laravel delivery model.

Own templates Guard editor changes Redesign in code
Compare WordPress
CMS capture: page structure Page families are defined once. A real Filament screen showing the registered page structures editors use instead of rebuilding content rules inside each page.
Public output: cache hit Public HTML stays separate from the admin. This anonymous frontend capture shows the output boundary: cached public HTML with no editor selectors, model identifiers, or signed authoring URLs.
Composer output: core package Capell installs as Laravel packages. Actual composer show output captured from this application, with the local repository path and build reference omitted.

Real Capell product screens

Actual Capell CMS page types screen showing registered content structures and their available editor actions.

The boundary can be inspected on one page. Capell prepares published content, links, media, and approved package contributions. The application component produces the HTML, applies the design system, chooses asset and cache behaviour, and ships through the normal release path.

A redesign changes project components and shared renderers while the content model remains available. An exit still requires migration engineering, but the public presentation and deployment path do not belong to a hosted builder.

Choose headless instead when multiple independent consumers genuinely need one content API and the extra network, permission, and operational boundary justifies its cost.

Frontend toolchain

One public-experience release path

The CMS prepares content and page context. The team keeps its components, asset build, quality checks, deployment, and replacement path.

The stack stays recognisable because Capell is installed into the application, not bolted on as a separate platform.

Map the Capell and application boundary

Use this ownership table to name the maintainer for the content schema, editor choices, templates, build, cache, and deploy path.

Scroll horizontally to view the full table.

Decision Capell Hosted builder Headless CMS
Templates Laravel project owns the public templates Builder or hosted platform often owns page composition Separate frontend app owns templates
Content schema Defined for the Laravel CMS boundary Often shaped inside the editing tool Defined in a separate content service
Editor changes Registered LayoutBuilder widgets and page types protect the public design Editors may shape layout directly in the visual tool Editors depend on preview and frontend wiring
Deploys Normal Laravel release path Platform release behaviour CMS deploy plus frontend deploy
Best fit Laravel sites that need editable structured pages Small sites where visual control matters most Many channels consuming one content API
Ownership checks

Redesign and exit boundaries

Can an admin-side change quietly affect what visitors see?

No. Core has no dependency on Admin, so authoring code cannot reach into the public render path. A visitor request resolves through Core and Frontend only, and receives hydrated content with no editor controls, field paths, or preview state, so an Admin change cannot silently alter public output.

Can editors publish without touching templates?

Yes. Editors work with approved page types, widgets, media, previews, URLs, and publishing flow while templates remain in the Laravel project.

Can we query our own content database?

Yes. Capell stores CMS records in the Laravel application's database, so application code can work with the content model directly where that is the right boundary.

Can we leave later?

Capell is not a hosted SaaS CMS. Leaving still takes engineering work, but the content, code, database, and deployment path remain in your Laravel estate.

Do we have to use one frontend stack?

No. Capell can prepare structured render data for Blade, Livewire, Inertia, Vue.js, cached HTML, or custom Laravel views. If the application needs its own endpoint, the application team designs, secures, and operates it.

Is this anti-headless?

No. Headless wins when many channels need one content API. Capell fits when the Laravel app owns the website and needs a real CMS inside that boundary.

Next step

A real-page render boundary

Follow the quickstart to trace one editable page into project-owned HTML. Use the headless comparison when multi-channel delivery may change the fit decision.

Ownership matrix The CMS should support the frontend boundary, not replace it.

Build the first public page Price a Laravel-owned build

Role scenarios

What to inspect in frontend delivery

Checks for public delivery, cache behaviour, frontend control, and output safety.

Role-based checks drawn from product capabilities and fit boundaries.

Agency team member representing this editorial scenario.

A cached page that queries the database fails

Render a cacheable public page that performs a database query. The render should fail visibly in development so a slow query cannot become part of the handed-over build.

Read more

The renderer treats a stray query on a cached page as a fault, so delivered performance does not quietly erode after handover. Public presentation stays the Blade and Tailwind the agency owns, not rented from a renderer agency teams cannot touch.

Trade-off to assess: It will not hand a client who wants to design every page a no-code canvas. A hosted builder fits better when the app does not need to own delivery or defend its own speed.

Run this yourself in the demo

Agency Director

Evaluator scenario for an agency director

Loading footer