Capell vs a custom Filament admin
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 22 July 2026 and describe Filament as of mid-2026. The application's own CMS capability must still be inspected directly.
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.
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 |
Prove the boundary with one difficult page
Choose a page with a public URL, reused media, editor preview, and a future layout change. Compare the implementation and ownership before planning a broader move.