Every admin product starts by rebuilding the same eight things — auth, RBAC, tables, forms, theming, i18n, feature flags, routing. None of it is the product. Here's why this keeps happening, and what to do instead.
Every internal tool, SaaS back office, and operational admin product begins life the same way. Someone opens an empty Vite project. The team picks a UI library. Then they spend three months building the same things every other admin product has already built.
Auth with token refresh. A permissions system. A data table that does server pagination, sorting, filtering, search, column reorder, and CSV export. A form stack with consistent validation. Empty states. Loading states. Error states. A notifications system. Light and dark themes. A language switcher. Feature flags. A routing setup that drives navigation and breadcrumbs from a single source.
Then — and only then — does the team start building the actual product.
This is the floor problem. The floor is the work you have to do before the product can stand on it. And almost nobody talks about how much of it there is, or how badly teams rebuild it.
The floor is bigger than people remember
If you've shipped one admin product, you remember the floor as a few weeks of setup. If you've shipped three, you remember it as months. The reason is that the floor reveals itself slowly:
- Week 1 looks easy. You have a sidebar, a couple of routes, a login page hitting
/auth. - Week 4 is where the table grows from "list of rows" to "server-paginated, with URL state, persistent column preferences, and a working CSV export."
- Week 8 is where permissions stop being a hardcoded
if (user.role === 'admin')check and become a real ability matrix that gates navigation items, route access, and individual action buttons. - Week 12 is where someone says "we need feature flags for the rollout," and now there's a config UI to build, a flag-checking hook to write, and a route guard to wire in. Multiply that by every admin product the team has built in the last five years and the cost gets uncomfortable. Most teams have rebuilt all of this — slightly differently — at every job.
What the floor actually contains
Here is the honest list. If you're building a serious admin product, you will need every one of these, and skipping any of them creates a worse version later.
Application foundation
- Authentication with session persistence and silent token refresh
- A state layer that survives reloads (auth, theme, language, table preferences)
- Centralized API error handling and notification surfacing
A routing system that drives the sidebar, breadcrumbs, and permission checks from one source of truth
Access controlA real RBAC model — abilities, not just role strings
Route-level guards
Component-level checks (hiding the "Approve" button when the user lacks the ability)
An admin UI to edit roles and abilities without a code change
Data UXA table with server-side pagination, sort, filter, and search
Column visibility, reorder, and resize, persisted per user
URL-driven state so a filtered view can be bookmarked or shared
CSV export
One canonical empty state, loading state, and error state across the app
A filter system that is declarative and serializable to URL and backend
FormsA form stack with consistent validation, error mapping from server responses, and a single canonical pattern
System featuresFeature flags with route- and component-level gating, plus a UI to manage them
Theme switching (light/dark) with no flash on reload
Internationalization with chained backends so translations can load from disk in dev and HTTP in production
A notifications system reachable from non-React code (RTK Query base queries, slices, anywhere)
Engineering conventionsA way to structure a page so every page in the codebase has the same shape
A scaffolding tool so new pages don't drift
A linter setup, a formatter setup, hooks for pre-commit, a circular-import detector
None of this is your product. All of it is required.
Why teams keep rebuilding it
You'd expect the industry to have solved this by now. There are component libraries, starter templates, admin generators, low-code platforms. What is everyone doing?
The honest answer is that the existing solutions cluster at two ends, and neither end works.
UI kits give you the parts. Material UI, Ant Design, shadcn/ui — these are excellent. They are also the bottom 10% of the work. They give you a <Table> component, not a data table that knows how to paginate against your backend. They give you a <Dialog>, not a confirmation pattern that fires a mutation and shows a notification. The rest is yours to assemble.
Starter templates give you a working layout. They tend to be demo-grade. The auth is fake. The permissions are a role: 'admin' | 'user' enum. The tables are client-side with hardcoded data. The first time you try to use one for a real workflow with statuses, sub-resources, and operator queues, it breaks down.
Low-code platforms give you a working product — until your requirements drift one millimeter from what the platform allows. Then you're working around the platform.
So teams keep rebuilding. Each rebuild is slightly different. Each team's "ConfirmDialog" works slightly differently. Each team's <DataTable> accepts slightly different props. The patterns proliferate, the codebases drift, and the second engineer on the project spends their first month learning bespoke conventions instead of building features.
The hidden cost: architectural drift
The visible cost of the floor is time. The hidden cost is drift.
If your codebase doesn't have a strong convention for what a page is, every engineer who touches it invents one. Some pages keep business logic in the component. Others extract a hook. Others use a Redux thunk. Six months later you have eleven different page shapes and the next new feature has to pick one.
If your codebase doesn't have a strong convention for tables, every engineer who needs a table picks a different one — server-side here, client-side there, with a custom wrapper on a third page. Now the user sees three subtly different table behaviors in the same product. Filter chips that look the same but behave differently. Pagination that resets in some places and persists in others.
If your codebase doesn't have a strong convention for permissions, the gating logic ends up sprinkled. Some routes check abilities. Some buttons check roles. Some components check ownership inline. Adding a new role becomes a code archaeology project.
This is what happens when there's no floor. Not catastrophe — just slow rot. The product becomes less coherent with every new module. Velocity decays. The third year of the codebase is much harder than the first.
What "good" looks like
A good admin foundation has three properties.
It is opinionated. There is one way to build a page. One way to define a route. One way to wire a table. One way to check a permission. The convention is explicit, documented, and enforced where it matters. A new engineer can read three pages and predict the fourth.
It is complete. Auth, RBAC, tables, forms, dashboards, notifications, theming, i18n, feature flags, routing — all of it is wired together and working. You can sign in, see a list, click into a detail, edit a record, get a notification, switch language, toggle dark mode, and have your column preferences persist across reloads. Out of the box.
It is real. It has been tested against an actual operational workflow with statuses, sub-resources, queue views, and decision flows. Not a demo of three CRUD screens. Patterns that survive the second module are very different from patterns that look fine in the first.
The "real" property is the one almost everyone gets wrong. Most templates pass the first two tests and fail the third. They have a working <Table>, a working <Form>, a working theme switcher — and then the moment you try to model a workflow with an item that has findings and evidence requests and a separate decision dimension, the template runs out of road and you're inventing patterns again.
A different way to think about it
The unit of admin software is not the component. It is the pattern.
A pattern is what happens when a component is used in the context of a real screen, with real data, real loading states, real error states, and real permissions. A <Table> is a component. "A server-paginated list with URL-driven filters, persistent column preferences, and CASL-gated row actions" is a pattern. The pattern is what teams actually need. The component is the smallest of the inputs to it.
If you build your admin product up from components, you spend the floor months assembling patterns. If you start from patterns, you spend that time on the product.
This is why component libraries, no matter how good, never compress the floor by the amount you expect. They solve the smallest layer. The patterns above them are still yours to build.
What to do about it
Three options, in increasing order of how much you give up:
- Build the floor yourself, but be deliberate. Pick the patterns up front. Document them. Enforce them. Scaffold them. Don't let twelve subtly-different table implementations grow in the codebase. This is the most flexible option and the most expensive. Worth it if your product is unusual or you have engineers who care about this.
- Adopt a foundation. Start from a codebase that already encodes the patterns and fork it into your product. The win is the months you don't spend on the floor. The cost is accepting somebody else's opinions on Redux vs. Zustand, MUI vs. Tailwind, MVVM vs. component-down. If their opinions are close to yours, this is the right trade.
- Use a low-code platform. Fastest start, hardest ceiling. Right when the product is small and unusual flexibility isn't a requirement. The middle option is the one most teams underuse, because the foundations they evaluate are usually starter templates pretending to be foundations. A real foundation has tested itself against a real workflow module, not three demo screens. The test is straightforward: open the demo, look for an entity with statuses and sub-resources and a decision flow separate from status. If it has all three, the patterns probably survive contact with reality. If it has none of them, you are looking at a UI kit with extra steps.
The floor is real. The cost of rebuilding it is real. The cost of not having a convention for it is bigger than the cost of building it once.
If you're starting an admin product this quarter and you've done this before, you already know which weeks are coming. The question is whether you want to spend them again.
Coreola is a production-ready React admin foundation that encodes these patterns — auth, CASL permissions, server-driven tables, forms, dashboards, feature flags, theming, i18n, and a working Assessments workflow module — in one opinionated codebase you fork into your product. Live demo at demo.coreola.com.