How to Add an Admin Panel to an App You Built with Claude or Cursor

Here's a pattern I've seen dozens of times over the past year, and I've lived it myself: you open Claude or Cursor, you describe an app, and a weekend later you have something real — an e-commerce store, a booking tool, a content site, a SaaS you've been meaning to build for months. The AI wrote the frontend, the routes, the schema, the whole thing.

Then comes the part nobody prepares you for: the admin panel.

Not the public-facing site — that part is done. I mean the back office. The screens where you approve a refund, edit a product, check who signed up this week, fix a record someone botched, look at yesterday's numbers. If you built the app with an agent, you probably don't have any of that. You have the database the agent created, and a growing pile of real data in it, and no good way to look at it.

This post is about the options you actually have for that situation, and the one I keep coming back to.

Why AI-Built Apps Are Missing an Admin Panel

When an agent builds an app, it optimizes for what you asked for: the user-facing experience. It'll happily generate login pages, dashboards for your customers, checkout flows, and polished CRUD for the parts of the app users touch. What it almost never generates, unless you explicitly ask, is the internal interface — the screens you use to run the business. That's not an agent failing; it's the same thing that happens when a human builds fast. The admin panel is boring, invisible, and easy to defer. "I'll build it later" turns into "later" being six months of editing the database by hand.

Meanwhile your database fills up with the stuff that matters: orders, users, refunds, support tickets, content. Every one of those rows is a decision waiting to happen — an order to ship, a refund to approve, a draft to publish. And the only tool you have to act on them is a SQL prompt or a raw database client showing you status: "pending" with no context.

The Four Ways People Solve This (And the Tradeoffs)

I've watched people handle the missing admin panel four different ways. All of them work. All of them have a cost.

Option 1: Hand-write the CRUD screens

The classic. You roll up your sleeves and build a routes file, a table component, a form component, and repeat for every table you care about. You've probably already done this once in your career — it's how most internal tools got built before AI.

Pros: Full control. It looks exactly how you want. It's "free" in the sense that you're not paying a vendor.

Cons: It costs your time, and time is the thing you were trying to save by using an agent in the first place. Every table is a new set of screens. Every schema change is a round of edits. For a solo developer this is days of work per app — and the app already took a weekend to build. Hand-writing an admin panel for an AI-built app is the most expensive way to finish the cheapest part of the project.

Option 2: Use the framework's built-in admin

Django has Django Admin. Rails has ActiveAdmin. Laravel has Filament. If your agent built the app in one of those frameworks, you can often flip on a generated admin in an afternoon.

Pros: It exists. It's tied to your models, so it knows your schema. Zero data leaves your machine.

Cons: It's tied to the framework. The moment your stack isn't Django/Rails/Laravel — and a lot of agent-built apps are React + API + Postgres, or a static frontend with a serverless backend — there's nothing to flip on. And framework admin screens are built for developers, not for "approve this refund" workflows. You still end up customizing.

Option 3: Adopt a cloud admin SaaS

Retool, Budibase, NocoDB's hosted version, Airtable — these are the tools that advertise "internal tools in minutes." Point them at your data and they generate a UI.

Pros: Fast. Polished. Team-friendly.

Cons: You're handing your production database credentials to a third party, and your operational data flows through their servers. For a side project that's annoying; for anything with real users it's a compliance conversation you don't want to have. You're also paying per seat or per editor forever for something that's fundamentally a CRUD interface — and if their service changes pricing or sunsets, your admin panel disappears with it.

Option 4: A local admin panel that connects to the database you already have

This is the approach I ended up building Basevolt around, and it's the one I use for every app I've shipped with an agent. It's a desktop app. You connect it to the database your app already uses — the same Postgres, SQLite, MySQL, or Cloudflare D1 database the agent created. It reads your schema as-is, no migration, no export, and turns it into a working operations panel: grid, kanban, gallery, dashboards, webhooks.

Pros: Your data never leaves your machine. No per-seat pricing, no cloud account. It works with the database you already have — nothing to migrate or rebuild. And because it sits on the same database your app talks to, what you see in the panel is exactly what your users see in the app.

Cons: It's a desktop app, so it's single-user by design — if you need five people logging in and editing the same records through a browser, this isn't that product. And you do have to connect it yourself, which takes about a minute.

The Part That Changed My Mind: Let the Agent Set It Up

Here's the thing that made option 4 click for me. You built the app with an agent — why shouldn't the agent build the admin panel too?

Basevolt runs an MCP server on your machine. The same Claude or Cursor that wrote your app can connect to it and configure the panel for you: field types, relationships between tables, the views that match how you work. You say "set me up a back office for orders," and the agent reads your schema and does the clicking you'd otherwise do by hand.

If you're thinking "I can already ask the agent to write admin code," here's the difference: the agent configuring Basevolt isn't generating code that reimplements your database — it's configuring a panel that reads your database. No new code to maintain, no deployment, nothing that can drift from the actual schema. When your schema changes, the panel reflects it. It's the difference between generating a photo of a house and walking into the house.

Setting It Up (Takes About an Hour, Mostly the Agent's)

Let me walk through what this actually looks like, using the store app I mentioned as the running example.

Step 1 — Connect the database the agent created.

Download Basevolt, add a data source, and point it at the same database your app uses. For Postgres that's host, port, database, user, password. For SQLite you just pick the .db file. It reads the schema as-is — no migration, no config file.

Step 2 — Enable MCP and let the agent configure the panel.

Open Basevolt's settings, enable the MCP server, and register it in Claude or Cursor (the app shows you the exact config for each client). Then in your agent, say something like:

Pull the store data into Basevolt and set me up a back office. Customers should show up by name, not ID. Statuses should be readable. I need a board for orders waiting on me.

The agent reads your schema, links the relations, types the fields, and sets up the views. What used to take me an evening of clicking now takes a few minutes of the agent doing it for me — and I can see every change it makes in the panel as it happens.

Step 3 — Actually run the business from it.

The next morning, instead of opening a SQL prompt, you open the panel. Orders waiting on you are a board. Pending refunds are a queue. Yesterday's numbers are a dashboard. When something needs your decision — approve, ship, refund — you click a button, and webhooks carry the action to your existing API. That's the whole loop: the agent built the app, configured the panel, and you run it.

The Honest Tradeoff

I'll be straight about the limits. If you're building internal tools for a team — five people who need logins, permissions, and a shared browser workspace — a local desktop app isn't the right answer, and you should look at Retool or self-hosted NocoDB. And if your app genuinely has no admin surface at all, like a static site with no database, there's nothing to attach a panel to yet.

But for the specific, increasingly common case of "I built an app with an agent and now I need to operate it" — the solo developer with real data and no back office — a local panel on top of your existing database is the fastest path, and letting the same agent that wrote the app configure it closes the loop. The admin panel is the part of the app nobody wants to write. With this approach, you don't have to write it at all.