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.
Capell 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.
Choosing what to build? Follow the practical application journeys: customer guidance, setup help and editorial catalogues around the records your Laravel application already owns.
Site ownership
Editorial workflow
Laravel delivery
Agency reuse
Choose the questions that matter to you
Owners, editors and developers need different evidence from the same publishing workflow.
A CMS decision usually involves more than one person. Editors want useful control, owners want accountable change and developers want a system they can maintain. The role guides below explain Capell through those responsibilities, so the group can compare one product against its different needs.
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.
Use a shared evaluation
Let each role inspect its part of the same real page.
Choose a page that matters to the organisation. The editor changes it and previews the result; the owner checks publication and recovery; the developer examines its definition, presentation and package requirements. An agency can use the same exercise to establish the handover responsibilities.
Keep the acceptance questions specific. A general approval of the demo does not prove the project's permissions, integrations or content model. Record the questions that need a pilot in your own application.
Agree who owns the result
Turn the CMS choice into a practical maintenance and publishing plan.
Editors need to know what they can publish and when review is required. Owners need to know who responds to a mistake. Developers need to know who maintains dependencies, deployment and custom application behaviour.
Capell helps make page changes repeatable, but it does not replace those responsibilities. Choose optional packages for the process the organisation needs, and keep licence and support expectations tied to current terms.
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.
Find the guide you need
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.
Next step
See the workflow in the live 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.