Rebuilding the Internal Admin Panel Nobody Wants to Touch

Almost every company we work with has one — the internal admin panel that started as a weekend project four years ago, got passed between three teams, and is now the single most important tool nobody wants to own. This is a post about rebuilding those without turning it into a two-quarter epic.

At Augere Labs we've done this rebuild often enough to see the shape of it clearly. The good version takes six to eight weeks and pays for itself in ops-team hours saved. The bad version becomes a nine-month replatform. The difference is a handful of decisions made early.

The hidden cost of a tired admin panel

The support team clicks through eleven screens to refund a customer. The ops lead has a Notion page of SQL snippets she runs because the UI doesn't do what she needs. The engineering manager quietly builds a bypass tool because the old panel keeps crashing on Fridays.

Nobody counts this cost. But if you total up the hours across support, ops, engineering, and finance, a bad internal tool eats real six-figure sums a year at any company past twenty employees.

Why these projects usually stall

Nobody wants to own it

Product doesn't count admin work as product work. Engineering counts it as tech debt. Ops uses it every day but doesn't set the roadmap. Without a clear owner, it never gets prioritized.

The scope explodes on contact

You start by "cleaning up the customers table" and end up questioning the entire permission model. Each thread you pull reveals two more. Without a hard scope, the project drifts.

The "let's use Retool" phase

Retool and Internal are excellent for the first stage of an admin tool. Past a certain point — usually when custom workflows, multi-step operations, or auditing become important — teams outgrow low-code and rebuild anyway. This is fine, as long as the second rebuild is scoped.

Our approach in eight weeks

Week 1 — Watch, don't design

Sit with the people who use the tool. Screen-record their workflows. Count how many actions they take to do the top ten tasks. This one week saves a month of guessing what to build. In projects like these, half of what stakeholders ask for isn't what they'd use.

Weeks 2–3 — Rebuild the top ten workflows first

Not the whole tool. The ten actions that make up 80% of daily use. A clean customer detail view, a working search, a refund flow that doesn't require three tabs. Ship these first, still alongside the old panel.

Weeks 4–5 — Add the ops layer

Bulk actions, audit logs, role-based access. This is where the old tool usually failed hardest. Modern stacks make it cheap: RLS in Postgres for row-level access, a small audit table, and a UI that shows who did what and when.

Weeks 6–7 — Add light AI where it earns its keep

Not everywhere. Places where it saves real time: a summarizer for customer notes, a natural-language search over support tickets, a "why did this account churn?" one-click investigation that pulls together the last 30 days of activity. See our take on building an internal AI tool for the pattern.

Week 8 — Migrate the last long-tail workflows and sunset the old panel

By now, users are already spending most of their time in the new tool voluntarily. Migration is a coordination problem, not a technical one.

Mistakes teams make

Trying to match the old UI exactly

The old UI is why you're rebuilding. Preserving its quirks preserves its problems. Start from the actions, not the layout.

Adding AI everywhere

Every admin action becomes "ask the AI to do it." Two months later it's slower than the old panel and less trustworthy. Use AI where it clearly beats a form, and use a form everywhere else.

Building without an audit log

Internal tools that can move money, change plans, or update user records must have a log of every action, who did it, and what changed. This is table stakes, and it's the single feature most legacy admin panels lack.

Skipping RBAC

"Everyone in the company can log in and do anything." That's how a curious intern accidentally emails 40,000 users. Roles from day one.

Where AI actually helps

Investigative queries

"Show me why account 4193's usage dropped last month." An LLM with tool access to your database, event log, and CRM can pull the summary faster than a human clicks through five screens. Great for support and CS teams.

Natural-language filters

Instead of a filter builder with twelve dropdowns, let users type "trials that signed up in July, hit the free limit, and haven't converted." Behind the scenes, this compiles to a query. This one feature is worth the whole project for some teams.

Draft actions, not final actions

AI suggests a refund amount, a churn message, a plan change. A human confirms. Never let the AI submit destructive actions on its own inside an ops tool.

The stack we tend to reach for

• Postgres with row-level security for isolation.
• TanStack Start or Next.js for the UI, since server functions map cleanly to admin actions.
• Supabase or Clerk for auth with roles.
• A minimal audit table with structured events.
• An LLM route behind a feature flag for the AI-assisted parts.

Nothing exotic. The gains come from good scope and clean primitives, not from any single tool.

A real example

A payments company we worked with had an admin tool built in a mix of Rails ERB and jQuery from 2016. Support was doing about 40 refunds a day, each taking three to five minutes. The team estimated a full rewrite at six months.

We shipped the top ten workflows in five weeks. Refund time dropped to under a minute. The nine-month "rewrite everything" plan turned into a two-month "polish and retire the old one" plan, and about $180K of estimated engineering work got redirected to actual product work.

Trade-offs

Custom always costs more than Retool in year one. It pays back if the tool is used daily by more than a handful of people, or if the workflows are complex enough that low-code becomes a bottleneck. Under those thresholds, stay on Retool.

AI features add latency and cost. Feature-flag them so power users get the boost and casual users get the fast path.

Common misconceptions

"We can just outsource this to a script." Scripts don't have audit logs, RBAC, or a UI that non-engineers can use. Every "just a script" ends up shadowed by a fragile ops workflow.

"An LLM chatbot on our database is the whole product." It's a nice front door. The real value is in the discrete workflows behind it — refunds, plan changes, permission updates — which need forms, confirmations, and logs.

Frequently Asked Questions

Should we buy or build our admin panel?
Buy (Retool, Internal, Superblocks) for early stage or generic CRUD. Build custom when you're doing repeatable workflows with real revenue impact and low-code starts getting in the way.

How long does a rebuild take?
Six to eight weeks for a well-scoped project. Longer if you try to rebuild everything before shipping anything.

Can we roll it out gradually?
Yes — run new and old side by side per workflow. Users tend to migrate voluntarily once the new tool is faster.

Where does AI actually pay off in admin tools?
Search, investigation, and drafting actions. Not everywhere, and never as the final actor on destructive operations.

Where to go next

If you want a broader view of internal AI tooling, read building an internal AI tool for your team. For the underlying engineering approach, see AI product engineering explained.

Working with us

Admin panel rebuilds are one of the highest-ROI projects we do. Talk to us if you're looking at a tool nobody wants to touch and wondering how to make it useful again.