What will the next redesign or set of page changes cost us?
- Start here
- Site owners
- What the page settles
- How shared structures, page history, and named ownership change the cost of repeated change, and where a smaller system would be enough.
Choose the Capell path for your role
Capell gives each person a different view of the same Laravel CMS. Owners need control over change and handover. Editors need a publishing path they can trust. Developers need clear package and frontend boundaries. Agencies need repeatable delivery that still leaves the client in control.
The four paths below are not four products. They read the same architecture from four positions: what a page change costs you, how safe it feels to make one, where the code for it lives, and how much of it survives into the next project. A director asking whether year three still looks affordable and a developer asking which package owns public output are both asking about the same page record.
Every page below also names the point where Capell stops being the right answer. A five-page brochure site that changes twice a year does not need structured page types, recorded publishing history, and installable capability; that is more system than the job requires, and each page says so before anyone installs anything.
Site ownership
Editorial workflow
Laravel delivery
Agency reuse
Capell is one Laravel CMS with different outcomes for the people who own, edit, build, and deliver the site.
Start from the responsibility you carry
Site owners can test whether repeated page changes, publishing history, supplier handover, and long-term operating costs stay understandable. Editors can follow a routine change from finding the right page through preview, publication, and page recovery. Developers can trace the split between Core, Filament Admin, public Frontend, and optional Composer packages. Agencies can judge whether the same structure makes the next client build more repeatable without taking ownership away from that client.
Each role page names where Capell fits, where a lighter option may be better, and what to verify before committing. The architecture remains the same across all four paths. The emphasis changes to match the decision in front of you.
Read more than one path when you carry more than one role
Most decisions here are made by two or three people who describe the same problem in different vocabulary. A director talks about the cost of the next redesign; a developer talks about coupling and upgrades; an editor talks about being able to fix a typo on a Friday afternoon. Those are three views of one question: how much does it cost to change this website next year, and who is allowed to do it. Reading two paths side by side is usually faster than arguing about which one matters.
What to verify before committing
Every path ends with questions to settle rather than a signup. Use the read-only demo to check the claims that matter to your role, then decide whether the structure is worth adopting. The honest answer for a small brochure site that changes twice a year is that a structured CMS with page history, approved components, and installable packages is more system than the job needs; the role pages say where that line falls instead of leaving you to find out after installation.
Four roles, four practical starting points
The paths share one product model: structured content in Core, a Filament workspace for editors, a public frontend owned by the Laravel application, and optional capability installed as Composer packages.
Pick the path that matches the decision you are being asked to make, not the job title on your contract. A technical founder often needs the owner path first and the developer path second. Read more than one when you carry more than one responsibility; the pages are written to be read in any order.
Next step
Test your own role's question in the demo
Open the read-only demo and try the one task your role would have to do every week.
Owners can look for a page's history and see who published it. Editors can follow a change from field to preview. Developers can compare the admin record with the public page. Agencies can judge how much of the structure would carry to the next client. One task each is enough to know whether the rest of the path is worth reading.
Match your question to a path
Can the marketing team publish without breaking the site or waiting on us?
- Start here
- Editors
- What the page settles
- The everyday path from finding a page to preview, publication, and recovery, plus the changes that still belong with developers.
Where does the CMS end and our Laravel application begin?
- Start here
- Developers
- What the page settles
- The split between Core, Filament Admin, public delivery, and Composer packages, with upgrade and output-safety boundaries named.
Can we deliver the next client site without rebuilding the last one?
- Start here
- Agencies
- What the page settles
- Which foundations, layouts, and packages become a delivery standard, and how handover leaves the client in control.
What every path is built on
surface
page records
route
https://capell.app/platform/content/page-building
state
structured
One structured content record
Pages are built from page types with named fields rather than free-form markup, so the same content can be edited, previewed, and reused without anyone retyping it. Owners see predictable change, editors see fields they understand, developers see a queryable record.
See page building
surface
cms surface
route
https://capell.app/platform/operations/publishing-workflow
state
structured
A publishing path with history
Every page save is recorded with its author, and any earlier page version can be compared field by field and put back without erasing the history in between. Approvals and scheduled releases arrive with the licensed Publishing Studio package when a team needs them, and stay out of the way when a single editor does not.
See the publishing workflow
surface
public render
route
https://capell.app/platform
state
clean output
Public output owned by your app
Capell holds the content; your Laravel application decides how it is presented. That keeps front-end work in Blade, Tailwind, and your own components rather than inside a theme system you cannot reach.
See the platform boundary
surface
package manifest
route
https://capell.app/platform/extensibility/packages
state
reviewable
Capability added as packages
Extra behaviour arrives as Composer packages with a declared install impact, so the foundation stays small and each addition is a decision someone made on purpose rather than a default you inherited.
See the package model