Building an Admin Panel for Your SaaS Without Losing a Month
Every founder underestimates the admin panel. It's usually the second-most-used surface in the product, and the least designed.
Every SaaS reaches the point where support tickets, refunds, and account debugging can't be done from psql anymore. The admin panel becomes the second-most-used surface in the product — used by your team, not your customers — and it's almost always the least designed. This is how we scope one without burning a month of engineering time.
The pattern below is what we ship on client projects when the founding team starts saying "I need to look up a user in the database again."
What the admin panel is actually for
Three jobs, in order of frequency:
- Customer support — look up a user, see their state, unstick them.
- Billing operations — refunds, plan changes, dunning fixes.
- Debugging — see what a user saw, understand why something failed.
Every feature you consider should map to one of those. Feature ideas that don't — analytics, cohort exploration, product-market-fit dashboards — belong in a separate tool. Mixing them is how admin panels turn into a two-month project.
The minimum viable admin panel
What we ship on week one:
User lookup
Search by email, by user ID, by workspace name. Show the last 10 events for that user, their plan, their billing status, and buttons for the four or five most common support actions.
Impersonation
The single most valuable feature. Let support log in as a user, see exactly what they see, and reproduce their issue. Every impersonation should be logged, and the impersonated session should be visually distinct — a red bar at the top saying "You are logged in as user X."
Impersonation without logging is a security incident waiting to happen. Every log entry needs the actor (support engineer), the target (customer), the reason (support ticket ID), and the timestamp.
Refund and plan change
Not a full billing UI — just the operations support runs weekly. Refund the last invoice. Change the plan. Extend the trial. Cancel the subscription. Each one wired directly to your billing provider's API.
Feature flag toggle per user
Turn a beta feature on for one customer. Turn a broken feature off. This lets support unblock users without a code deploy.
That's it for week one. Everything else can wait.
What to add in month two
Once week one is in production and getting used, the patterns of what's missing become obvious. Common additions:
- Audit log viewer — what did this user do in the last 30 days.
- Data export on demand — support asks for a CSV of a user's records.
- Manual data fix UI — bulk update a field for a specific customer.
- Team invite override — resend an invite that got lost.
- Usage overrides — bump a customer's rate limit for the day.
Every one of these should come out of a real support ticket. If nobody has asked for it, don't build it.
Build vs Retool vs internal PaaS
The eternal admin panel question.
Retool, Appsmith, Superblocks
Fastest for the first version. Wire up your database, drop in tables and forms, ship in 2-3 days. Good for teams under 20 people where the admin panel is only used by a few support engineers.
The pain shows up around 12-18 months. Retool builds don't version-control cleanly, engineers can't refactor them like normal code, and permissions get complex. Fine for a while, then a migration you have to do.
Custom admin routes in your app
What we recommend for most product-focused SaaS. A protected /admin route in the same codebase, using the same auth and the same components. Engineers can add features in an afternoon because it's the same stack they already know.
Downside: everything you build has to be built. There's no drag-and-drop table generator. For basic CRUD-heavy admin needs, this is slower to start.
Framework-based admin (react-admin, Refine, Forest Admin)
Middle ground. Generates CRUD UIs from your API but lives in your codebase. Faster than pure custom, more flexible than Retool. Works well if your admin needs are heavily CRUD-shaped.
Our default
Custom admin routes for anything the product team owns. Retool for anything the finance or ops team owns. That split works because it aligns tools with the team that maintains them.
Permissions and security
The admin panel is where security incidents happen. A support engineer with too much access can leak customer data, delete accounts, or issue refunds they shouldn't. Design permissions early or regret it later.
Role-based access
At minimum three roles: read-only support (can view users, can't change anything), full support (can impersonate, refund, adjust plans), and admin (can manage roles and access sensitive settings). Start with those and split further only when a real reason shows up.
Sensitive actions require a reason
Every destructive action — deleting an account, issuing a large refund, exporting bulk data — should require typing a reason. It's a small friction and it turns every action into an audit trail.
Second-factor for admin login
Not optional. The admin panel is the highest-value target in your app. Any support account without 2FA is one phished password away from being a lawsuit.
Audit logs — build them from day one
Every admin action needs to be logged. Not "we'll add logging later." Day one. If a customer ever asks "who changed my account," you need to answer, and the answer needs to be defensible.
The audit log should record: actor (which support engineer), action (what they did), target (which customer), reason (free-text or ticket ID), timestamp, and IP address. Store it in an append-only table. Never let it be edited.
Our note on handling PII covers how this fits with data protection obligations.
Impersonation done safely
Impersonation is powerful and dangerous. Get it wrong and you've written a bypass around your own auth.
The right pattern: impersonation is a separate session. Your JWT (or session cookie) carries both the real actor and the impersonated user. Server-side, every action is authorized as the impersonated user but logged as the real actor. UI shows the banner and disables destructive customer actions unless explicitly approved.
What we don't recommend: swapping the session entirely so the support engineer's session becomes the customer's session. That works, but it strips the audit trail. If a support engineer takes a destructive action while impersonating, you want the log to show both identities.
Common mistakes
Building admin as an afterthought. The panel gets used dozens of times a day. Ugly slow admin costs your team hours every week.
Overbuilding on day one. Analytics dashboards, cohort explorers, ML-powered recommendations. All future work. Ship the four features above and iterate.
Skipping audit logs. The one thing you'll regret when your first serious support incident happens.
Giving everyone admin. "Just make me admin, it's faster." Fine for a team of three. Terrible at ten. Set the roles early.
Retool without a migration plan. Retool is great to start. It becomes a lock-in over time. If you use it, know when you'll graduate off and what you'll graduate to.
Trade-offs
A well-built admin panel reduces support cost meaningfully. It also increases blast radius when things go wrong. A support engineer who can fix a customer in 30 seconds can also break a customer in 30 seconds. Guardrails matter — confirmations, reason fields, and audit trails aren't UX friction, they're accident prevention.
Common misconceptions
"Admin panels are boring, we'll figure it out." Every founder says this. Every founder later says "I wish we'd built this six months earlier."
"Retool is only for MVPs." Retool is used at unicorn-scale companies for internal ops. It just needs discipline and a migration plan.
"Impersonation is unnecessary if support has SQL access." SQL access shows the data. Impersonation shows the experience. Different tools for different problems.
Frequently asked questions
Final take
The admin panel is the highest-leverage internal tool most SaaS ship. Build the minimum viable version early — user lookup, impersonation, refunds, feature flags — with audit logs from day one. Add features when real support tickets demand them. Choose Retool when you need speed and don't have a product engineer to spare; build custom when the panel is part of the product's core operations.
If you're scoping an admin panel and want a reference implementation, book a call. We've shipped a dozen of these and the pattern is stable.
FAQ
Frequently asked questions
Should the admin panel live in the same codebase as the product?+
Usually yes. Sharing auth, components, and data models makes the panel cheap to extend. The exception is when the panel is used by non-engineers doing operational work — finance, support ops — where a Retool build lets them own it without engineering involvement.
Is Retool secure enough for production?+
Yes, if you configure it well. Retool supports SSO, role-based permissions, and audit logs. The security concerns are usually operational — teams give too many people access, or wire it directly to production with no read/write split. That's a discipline problem, not a Retool problem.
What's the difference between an admin panel and an internal tool?+
Admin panels are customer-facing operations: support, billing, account debugging. Internal tools are team-facing operations: analytics, cohort analysis, marketing campaigns. They often use the same technologies but serve different jobs. Mixing them into one 'admin' surface is a common mistake that leads to a two-month project.
Do I need impersonation from day one?+
If you have paying customers and any support burden, yes. Nothing accelerates support like being able to see what the customer sees. Just log every session, show a visible banner, and require a reason. Impersonation without those three is a security hole.
How much time should the admin panel take to build?+
Version one — user lookup, impersonation, refunds, feature flag toggle — should be 1-2 engineer-weeks in a codebase that already has auth and a data layer. If it's taking a month, scope has expanded past what week one needs.
Building something similar?
Let's talk in 30 minutes.