CMS, Framework Admin, Internal-Tool Builder or Custom: How to Choose Your Admin Panel

Use a CMS for marketing content. Use a framework admin (Django admin, Laravel Filament or Nova) when a small, trusted team needs to manage records in an app you already build on that framework. Use an internal-tool builder (Retool, Appsmith) for operational screens that pull from several systems and change often. Build a custom admin for processes that are high-risk, multi-step or used by your customers' own administrators. Most products end up with two of these, not one.

The question is often asked as "CMS vs custom admin panel", but that frames it as a choice between two versions of the same thing. They are different jobs, and the right tool depends on which job each screen does. This guide is for founders, product and operations leads scoping a back office for a product that already exists or is being built.

Django's documentation draws the line clearly. It says: "The admin's recommended use is limited to an organization's internal management tool. It's not intended for building your entire front end around." It adds: "If you need to provide a more process-centric interface that abstracts away the implementation details of database tables and fields, then it's probably time to write your own views." (Django 6.1 admin docs). The same logic applies to every option below: tools that expose records are fine for people who understand the records, and processes need screens designed around the process.

A CMS, traditional or headless. Built for publishing. Some, such as Directus, describe themselves more broadly: its repository says it can "Turn your DB into a headless CMS, admin panels, or apps" over SQL databases, with generated REST and GraphQL APIs. Note its licence: the repository now states the Monospace Sustainable Core License (MSCL) 1.0, source-available, free for organisations under $5M annual revenue and 50 employees (Directus on GitHub, vendor). For content-only decisions, see how to choose a CMS and custom CMS vs WordPress.

A framework admin. Django ships an admin with bulk "actions" on selected records and a built-in "delete selected objects" action, and its LogEntry model tracks additions, changes and deletions made through the admin (Django admin actions). On Laravel, Filament is MIT-licensed and describes itself as a way to "Build and ship apps & admin panels fast with Livewire" (Filament on GitHub); it includes actions to import rows from a CSV and export to CSV or XLSX. Laravel Nova is a paid admin package (prices below).

An internal-tool builder. Retool and Appsmith let you assemble screens over databases and APIs with less code. Appsmith's repository describes it as a "Platform to build admin panels, internal tools, and dashboards" and is Apache-2.0 licensed (Appsmith on GitHub). Both offer hosted and self-hosted versions. For the wider low-code question across whole business applications, see low-code vs custom software.

A custom admin. Screens built in your product's own codebase around specific processes, with permissions and audit designed for them. It costs the most to build and has no licence fee.

Find the jobs your team does every day in the left column. Where most of your rows point the same way, that is your default; where one row points elsewhere, that screen may deserve a different tool.

Score each candidate against these before comparing screenshots. The usability of a back office matters, but these requirements are what decide whether it is safe to use and possible to change later.

Prices are vendor list prices shown on each vendor's page on 15 October 2026, in dollars as displayed, excluding tax. They change. No build costs are given, because they depend entirely on scope.

Hypothetical example: a two-sided marketplace with a marketing site, a buyer app and a seller app, run by a small operations team.

The marketing site's pages and blog sit in a headless CMS, because editors need previews and publishing and nothing more. The operations team manages listings, categories and user look-ups in the framework admin that ships with the backend, with roles limiting who can see payout details. Bulk fixes go through admin actions that show the affected records first.

Two jobs did not fit. Seller onboarding needs document checks, two reviewers and a reason for every rejection, so it gets a custom review screen with maker-checker and its own audit trail. Sellers managing their own staff is customer-facing, so it lives inside the seller app with tenant-scoped permissions. An internal-tool builder could have handled the review queue too; the deciding factors would be how many staff use it, where the documents are stored, and whether the builder may hold credentials to that data.

A CMS is the wrong choice for transactional records. It lacks the permission model, audit trail and validation that money and accounts need, and bending it creates a fragile back office.

A framework admin is the wrong choice for people who do not understand the underlying records, for multi-step processes, and for anything customers use. Django's own docs say it is not intended for building your front end around. Be careful with defaults: Django's built-in bulk delete uses QuerySet.delete(), so a model's own delete() method is not called.

An internal-tool builder is the wrong choice when per-user costs at your real staff numbers exceed the cost of maintaining code, when the tool would need broad production credentials, or when hosting and data location rules rule out the hosted version and you cannot run the self-hosted one well. Business logic built inside the builder is hard to move.

A custom admin is the wrong choice for simple record editing that a framework admin already does, or when nobody will fund maintenance. Every screen is code to test and update.

If you are still deciding whether the product needs application features at all, start with custom website vs web application.

Framework documentation: Django 6.1: the Django admin site; Django: admin actions; Filament repository (MIT); Filament import action; Filament export action.

Vendor pages: Laravel Nova; Retool pricing; Appsmith pricing; Appsmith repository; Directus repository.

Security guidance: OWASP Authorization Cheat Sheet.

Accessed 15 October 2026. Prices, licences and plan features are vendor data and change; check the current pages before deciding.

List the five things your operations team does most often, and the two that would hurt most if done wrong. Put each in the job matrix, then score your shortlist against the requirements checklist, including licence cost at three times today's headcount. Keep marketing content in a CMS whatever you choose, and design anything customers touch as part of the product. If the back office is part of a larger build, it belongs in the same web application development scope as the product, with the admin screens designed for the people who use them every day.