Choose which optional cookies Capell may use.
Required for Capell to work — login, security, page rendering.
Anonymous usage telemetry to improve editor performance.
Personalization for the Capell marketing site.
Developers should not have to choose between editor tooling and frontend ownership. Capell keeps CMS records, admin screens, package extension points, and public delivery inside the Laravel application.
That means Actions, data objects, policies, service providers, render hooks, tests, migrations, queues, Scout, and Filament can all remain part of the same engineering workflow.
Capell needs to feel like Laravel work. Developers already have tools they trust: Composer, service providers, migrations, Actions, data objects, policies, tests, queues, Blade, Livewire, and Filament. The CMS should fit that world instead of adding a second engineering culture.
The point is inspectability. Public rendering stays in the app. Optional features arrive as packages. Admin behavior stays in Filament. Repeated page structures get names the team can review and test.
The bar is ordinary Laravel maintainability applied to CMS work that usually drifts out of shape. If a developer cannot explain how a public page is built, the CMS has already become too expensive.
Capell keeps CMS work close to Actions, data objects, tests, static analysis, Composer packages, and project-owned frontend builds.
The stack stays recognisable because Capell is installed into the application, not bolted on as a separate platform.
Capell should not hide the CMS from developers. It should make CMS behavior explicit enough to build, review, test, extend, and replace without archaeology.
Build Laravel CMS features with Actions, data objects, page types, render hooks, packages, tests, and Filament admin boundaries.
Start with the practical question: what does the visitor or editor need to do next? Capell keeps that answer tied to the Laravel app, with shared structures for repeated pages and enough room for custom work when the project genuinely needs it.
Capell is for Laravel teams that want CMS structure without giving up application ownership.
No. The public site can use Blade, Livewire, Inertia, Vue.js, or custom rendering while Capell provides CMS context.
Yes. Packages are normal Laravel packages, so behavior can be covered with Pest, feature tests, browser tests, and package-level checks.
Keep product behavior in application Actions, services, models, jobs, and policies. Capell should provide CMS structure, not swallow the app.
The next step is capability added through packages: decide which CMS features belong in reusable packages and which should stay local to the application.
Developer boundary Actions, DTOs, packages, render hooks, policies, and tests keep the CMS understandable.
Reviews
Simple feedback on keeping CMS structure inside Laravel.
One content model the Laravel app already owns
“Capell Core puts pages, URLs, layouts, media and translations behind one typed model inside the Laravel app. Content can grow without a new bespoke admin screen each time, and rendering stays in the codebase the team already maintains.”
The content model you keep, not rent
“For a site owner, Capell Core means the structure behind every page, URL and translation lives in the app you own, not a hosted account someone else controls. The site can grow for years without being tied to a vendor's roadmap.”
One core to deliver every client on
“For an agency, Capell Core is a shared content model the whole studio learns once and reuses on every build. Pages, URLs, media and translations stop being re-invented per project, and support stays predictable across the client base.”
The developer experience is intentionally practical: keep the CMS inside Laravel, keep public rendering in project code, and add optional capability as packages. That gives teams room to extend the CMS without losing the ability to review, test, and deploy it normally.
| Area | Capell shape | Developer check | Team outcome |
|---|---|---|---|
| Application boundary | Capell runs inside the Laravel app instead of beside it. | Use existing Laravel practices for config, routes, policies, jobs, events, and tests. | The CMS feels like part of the product rather than an external platform. |
| Rendering boundary | Frontend output is prepared and rendered by the app team. | Build Blade, Livewire, Inertia, Vue, or custom renderers around approved data. | Design changes do not require replacing the CMS. |
| Extension boundary | Packages add focused CMS features with declared install impact. | Review each package like any dependency: migrations, service providers, views, commands, and public output. | Capability grows while core stays focused. |
| Maintainability | Repeated structures become page types, layouts, widgets, and assets. | Prefer shared contracts over one-off page templates when behavior repeats. | Year-five maintenance stays visible instead of buried in bespoke screens. |
Keep product rules in application Actions, services, policies, jobs, and tests. Capell gives the CMS a durable shape, while the app team keeps responsibility for domain behavior, release timing, and deploy decisions.
Developer pathWhen pages share behavior, define page types, layouts, widgets, assets, and metadata contracts instead of copying another template. The payoff is boring maintenance: one shared rule can improve every repeated page.
Content managementBefore installing a package, understand the setup path, data it adds, public surfaces it can affect, and operational work it may introduce. Treat CMS capability like any Laravel dependency that deserves code review.
Package-based featuresPublic Blade, Livewire, Inertia, or Vue output should receive resolved content, links, media, and approved package contributions. That keeps visitor pages clean while still letting the frontend team own presentation.
Render rulesCapell learning journey
Capell is a Laravel CMS split into four parts: Core, Admin (Filament), Frontend, and Packages. See how they fit your project.
Packages, developer workflow, and AI assistance.
