Skip to main content
Capell home
Live demo

Capell vs a custom Filament admin

Scope a custom-admin migration See Capell in Filament

Keep a bespoke Filament resource when only a few stable records need editing. Do not replace useful resources to standardise the stack. Count the CMS work the team now owns: public URLs, page families, previews, reusable media, editor composition, redirects, history, and release checks.

Filament framework claims were checked against first-party public documentation on 2 October 2026 and describe Filament as of October 2026. The application's own CMS capability must still be inspected directly.

Keep purpose-built application resources Count repeated CMS maintenance Pilot one page family before moving
CMS capture · Content index Every page and its structure stay visible in the admin. The populated Pages index keeps page hierarchy, publish status, update time, page type, and PageSpeed state visible beneath its SEO overview.
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.

Capture date and release are not supplied in this gallery. Check the current package listing for scope and compatibility.

Real Capell product screens

Actual Capell CMS Pages index showing its SEO Overview and columns for Page, Publish status, Updated at, Page type, and PageSpeed.

Keep custom work where it matters

Use bespoke Filament resources for your business, and evaluate Capell when publishing becomes repeated infrastructure.

Custom Filament is a sensible choice for a few stable editable screens. The question changes when the team repeatedly builds page URLs, preview, history and recovery around them. Compare how much of that publishing work you want to own before adding another custom page resource.

Capell populated page editing screen
Compare the complete editing workflow with the fields and screens your team would otherwise maintain.

A custom Filament admin is the better fit when the application needs a few stable, application-specific admin screens. The team gets direct control over forms, tables, policies, model actions, and domain behaviour without adopting a broader page model.

Count recurring CMS work

Reconsider the local approach when the same concerns appear across public page families: URL history, redirects, previews, reusable media, page composition, shared layouts, translation, search metadata, change history, and cache invalidation. The threshold is repeated ownership, not an arbitrary number of resources.

Keep what already expresses the domain well

Capell can sit beside existing Filament resources. Orders, accounts, catalogue operations, or project-specific approval actions should remain local when they are not CMS concerns. Draw a boundary around pages and publishing instead of replacing a working admin wholesale.

Run a representative pilot

  • Choose one routine page and one page with awkward routes, custom actions, reused media, and editor expectations.
  • Map which model logic stays and which page behaviour moves to the shared CMS model.
  • Verify public HTML, redirects, metadata, cache behaviour, and the editor task.
  • Keep the old route recoverable until acceptance passes.

Choose Capell only when the maintained page foundation removes more work than adopting it creates. If the admin remains small and stable, continuing with custom Filament is the simpler and better engineering decision.

Recognise repeated publishing work

Distinguish the unique business rule from the CMS machinery around it.

A business resource may need application-specific validation and actions that should remain custom. Repeated public pages add different needs: consistent fields, templates, URLs and a clear editorial workflow. Copying another resource can be quick initially but leaves more places to maintain later.

Capell gives those repeated page concerns a shared home while your application keeps its own business behaviour. Trial the boundary rather than moving every existing model into the CMS.

Compare the maintenance burden

Include the next redesign and the first editorial mistake.

Ask the custom build to show how a page family changes together and how an editor compares or recovers a mistake. Those features may be entirely achievable in your own code; the decision is whether maintaining them is a good use of your team's time.

A small set of stable resources may remain simpler without a CMS layer. Choose Capell when the publishing requirements repeat enough to justify shared infrastructure, not to replace useful application-specific administration.

Compare what the team agrees to maintain

Both choices use Filament. Compare the surface area that remains application-specific with the CMS behaviour that should improve across many pages.

Scroll horizontally to view the full table.

Decision Capell Custom Filament
Best starting point A growing public site with repeated page concerns A small set of stable domain screens
Domain records Coexists with project-specific resources Purpose-built forms and actions remain direct
Pages and URLs Shared page records, routes, URL history, and redirects Designed locally if the application needs them
Editor changes Approved layouts and previews use a maintained page model The team designs each form and preview path
Public output Application templates receive prepared page data without editor metadata The project defines and tests every public contract
Maintenance Shared CMS behaviour changes through versioned packages Local behaviour stays under the application team's ownership

What does adopting Capell add?

Start with the extra abstraction and footprint. Compare against a production-ready custom Filament CMS doing equivalent work.

Credit a production-ready Filament build

Compare against shared Blade components, Laravel policies, Actions, Data objects, selected packages and proper caching. Both approaches can support the same public output and one shared-view design change. Filament resources and structured editor fields are already useful tools. Capell adds another model and dependency surface; adopt it only when its coordinated Page lifecycle is worth that commitment.

Capell supplies Page history, comparison and validated recovery, URL/content lifecycle conventions and maintained CMS integration. A competent custom CMS can implement equivalent behaviour. Both still need the appointment association, domain rules, permissions, prepared-data adapter, views and freshness integration. If the existing CMS meets those requirements, migration may add little value.

Read the direct constraints before adopting the model

This is a source inventory from the five Foundation Composer manifests, not a solved minimum installation, transitive dependency closure, incremental package count or runtime result. Core, Admin, Frontend, Installer and Marketplace are the five MIT Foundation packages. The broad marketing/account/commerce App installation is not a minimal Foundation benchmark.

Check overlap against the host lock: an existing dependency is not wholly incremental, but another version constraint still matters. A disabled CMS feature does not remove a library required by Composer. Resolve compatibility in the actual host application before adoption.

Read the direct constraints before adopting the model
Layer Declared requirement or work What remains to check
Existing host Its actual PHP, Laravel, Filament, policies, selected packages and caching Record the host lock and its current operational requirements
Core PHP ^8.4, ext-intl, Illuminate ^13.0 and Filament Support ^5.7.6; event sourcing, media, permissions, settings, tags and relationship libraries Dependency overlap, schema/migrations, providers and version conflicts
Admin Laravel ^13.0 and Filament ^5.7.6; fileinfo, intl and simplexml; editor, media/settings and administrative integrations Existing panel compatibility, permissions and authoring runtime
Frontend Laravel ^13.0, ext-dom, Livewire ^3.0|^4.0, image, HTML sanitisation and minification dependencies Current rendering contracts, runtime strategy and delivered assets
Installer PHP ^8.4, ext-intl, Core ^1.0 and Spatie package tools ^1.14.1 Installer provider, installation/upgrade machinery and host overlap
Marketplace PHP ^8.4, Laravel ^13.0, Admin/Core ^1.0, Actions, Data, settings and package tools Catalogue provider and integrations; check version overlap against the host lock
Optional features Layout Builder composition, Publishing Studio workflow, HTML Cache and optimisation are separate choices Dependencies, activation, migrations, schedules/workers, browser/build tools, permissions and licence obligations

Direct manifest receipt, read on 23 October 2026

These are the direct production requirements and declared providers in the inspected source manifests. Development requirements are excluded. This receipt does not resolve dependencies against another application, include transitive requirements, prove installability, or measure registered or executed work. Recheck the target release manifests and host lock before adoption.

Direct manifest receipt, read on 23 October 2026
Foundation package Direct production declarations Declared provider
capell-app/core php ^8.4; ext-intl *; aimeos/laravel-nestedset ^7.0; awobaz/compoships ^2.3 || ^3.0; bkwld/cloner ^3.10; filament/support ^5.7.6; illuminate/database ^13.0; illuminate/support ^13.0; laravel/prompts ^0.2|^0.3; livewire/blaze ^1.0; lorisleiva/laravel-actions ^2.8; monolog/monolog ^3.10; psr/log ^1.0|^2.0|^3.0; spatie/laravel-activitylog ^4.0 || ^5.0; spatie/laravel-data ^4.5; spatie/laravel-event-sourcing ^7.15; spatie/laravel-medialibrary ^11.0|^12.0; spatie/laravel-permission ^5.0|^6.0|^8.0; spatie/laravel-settings ^3.0; spatie/laravel-tags ^4.11; staudenmeir/eloquent-has-many-deep ^1.7; staudenmeir/eloquent-json-relations ^1.1; symfony/filesystem ^7.2|^8.0; symfony/html-sanitizer ^7.0|^8.0; symfony/process ^7.2|^8.0 Capell\Core\Providers\CapellServiceProvider
capell-app/admin php ^8.4; ext-fileinfo *; ext-intl *; ext-simplexml *; amidesfahani/filament-tinyeditor ^4.0|^5.0; bezhansalleh/filament-shield ^4.1; capell-app/core ^1.0; cms-multi/filament-clear-cache ^3.0; codewithdennis/filament-select-tree ^4.0; filament/filament ^5.7.6; filament/spatie-laravel-media-library-plugin ^5.7.6; filament/spatie-laravel-settings-plugin ^5.7.6; guava/filament-icon-picker ^3.0|^4.0|^5.0; guzzlehttp/guzzle ^7.5|^8.0; lara-zeus/spatie-translatable ^1.0|^2.0; laravel/framework ^13.0; laravel/prompts ^0.2|^0.3; laravel/serializable-closure ^2.0.10; lorisleiva/laravel-actions ^2.8; saade/filament-adjacency-list ^4.0.2; spatie/laravel-activitylog ^4.0 || ^5.0; spatie/laravel-package-tools ^1.15; stechstudio/filament-impersonate ^5.3; tanmuhittin/laravel-google-translate ^2.4 Capell\Admin\Providers\AdminServiceProvider
capell-app/frontend php ^8.4; ext-dom *; blade-ui-kit/blade-heroicons ^2.5; capell-app/core ^1.0; guzzlehttp/guzzle ^7.5|^8.0; intervention/image ^3.0|^4.0; laravel/framework ^13.0; laravel/prompts ^0.2|^0.3; livewire/livewire ^3.0|^4.0; lorisleiva/laravel-actions ^2.6; michaloravec/laravel-paginateroute ^1.0; spatie/laravel-permission ^5.0|^6.0|^8.0; spatie/laravel-translatable ^6.0; symfony/html-sanitizer ^7.0|^8.0; voku/html-min ^5.0 Capell\Frontend\Providers\FrontendServiceProvider
capell-app/installer php ^8.4; ext-intl *; capell-app/core ^1.0; spatie/laravel-package-tools ^1.14.1 Capell\Installer\Providers\InstallerServiceProvider
capell-app/marketplace php ^8.4; capell-app/admin ^1.0; capell-app/core ^1.0; laravel/framework ^13.0; lorisleiva/laravel-actions ^2.8; spatie/laravel-data ^4.5; spatie/laravel-settings ^3.0; spatie/laravel-package-tools ^1.14.1 Capell\Marketplace\Providers\MarketplaceServiceProvider

Installed, enabled, registered and executed are different

The inspected default runtime role is Combined. A deliberately configured Public role can filter authoring providers; it neither removes Composer dependencies nor switches automatically for every anonymous URL. Account for existing host Filament functions before choosing a deployment topology.

Separate required Core/Frontend services and route/kernel work from Admin authoring providers, Installer/Marketplace integration and selected optional providers. Installed-runtime enablement hooks do not establish zero earlier provider or middleware work. A disabled middleware path may still execute its guard. Only request measurement can establish the cost for a selected configuration.

The appointment specimen uses an ordinary application route and a no-store response. Its source explains lookups and hydration; it does not measure request cost. Request memoisation elsewhere in this App is not cross-request caching. The actual App catalogue bridge uses optional Layout Builder, returns array projections and performs per-card Extension and screenshot work; it is an integration precedent, not a Foundation minimum or benchmark.

Make the adoption decision against the next change

Follow the complete appointment example at /solutions/roles/developers#developer-appointment-evidence: provider and fields, scoped Action, Data, invoked controller and route, shared master/wrapper and an independent route. The focused design diff gives both Capell and custom Filament equal credit for view reuse.

The Page schema extension used there is a current Admin contract that must be checked against the installed version. The public render-data contributor is experimental and is not used by the specimen. Upgrades still require dependency resolution, adapter checks, stored-content migration where needed, backups and deployment sequencing. A compatibility declaration does not validate booking behaviour or guarantee every extension will boot.

Keep custom Filament when existing CMS contracts are sufficient, compatibility or operational constraints conflict, or migration and adapters exceed the missing benefit. Evaluate Capell when the project wants to adopt its Page lifecycle and accepts the model, dependencies and operating obligations. No page-count threshold, maintenance saving or speed advantage is established.

Threshold checks

When custom Filament resources are enough

Which custom resources should remain untouched?
Keep resources that express stable application workflows well. A migration should identify the page concerns Capell will own, not turn every domain record into CMS content. Separate keep and move decisions
Are URL history and redirects now recurring product work?
List every local route helper, redirect table, slug mutation, canonical rule, and cache invalidation path. Repetition across page types is a stronger signal than one complicated route. See the page model
Can editors complete the difficult page without a bespoke release?
Run the real task with the people who publish it. Record which fields, previews, custom actions, and developer hand-offs are essential before changing the admin. Run the editor task
Can the old and new page models coexist during a pilot?
Yes, if each URL and record has one owner. Keep existing resources in place, route a bounded page family through Capell, and define the rollback before traffic moves. Design the coexistence pilot
Loading footer