Your Internal Admin Panel Is Technical Debt
Almost every company builds one. The internal admin panel. The little tool where support can look up a user, ops can check an order, someone can toggle a feature flag. It starts as a single page and ends as a sprawling app that an engineer maintains forever and nobody ever fully trusts.
I've built a few of these. I now think most of them are a mistake, or at least a much worse deal than they look when you start.
How it always goes
Day one, someone needs to look up a customer's subscription status to answer a support ticket. So you build a page. Just a search box and a table. Twenty minutes of work, ship it, everyone's happy.
Then support needs to see the customer's payment history too. Add a tab. Then they need to issue a refund, so you add a button, which means you need a confirmation flow, which means permissions, because not everyone should refund. Then ops wants a different view entirely. Then someone wants to export. Then the search is slow, so you add an index, then pagination, then filters.
Eighteen months later you have a second application. It has auth, a permissions model, a dozen views, and a backlog. No customer ever sees it. It generates no revenue. And it needs an engineer's attention every time the underlying schema changes, which is constantly, because it's coupled directly to your tables.
The debt isn't the code, it's the coupling
The reason I call it debt isn't that admin-panel code is bad. It's that the admin panel is a hand-built, hard-coded interface to data that's already perfectly queryable. You took a database that can answer any question and wrapped it in an app that can answer only the questions you pre-built screens for.
Every new question is now an engineering ticket. Support needs a view you didn't anticipate? Ticket. Ops wants to slice by a field you didn't add a filter for? Ticket. The admin panel doesn't reduce the data-access workload. It just moves it into a UI and makes each new request require a deploy.
And it ages badly. The panel knows your schema as it was when each page was written. Rename a column and three views break silently. The maintenance never ends because the coupling never loosens.
What it was really solving
Strip it down and the admin panel exists to solve one problem: non-engineers need to read and occasionally act on production data, and you don't want to give them a raw database connection.
That's a real problem. The admin panel is one answer to it. It's just an expensive, rigid answer, because it solves "let people see the data" by predicting in advance every question they'll ask and building a screen for each. Prediction is the part that doesn't scale. People always ask the question you didn't build.
The alternative I'd reach for now
What you actually want is for non-engineers to ask questions of production data safely, without an engineer pre-building a screen for every possible question. That's a different shape of solution.
Read access with real guardrails — read-only, scoped to the right tables, row-level permissions, an audit log — gets support and ops most of what the admin panel gave them, without you maintaining a second app. When a question doesn't have a screen, they ask it directly instead of filing a ticket for you to build one. The data was always queryable. You stop hiding it behind hand-built views.
This is most of why I built QueryBear, so discount accordingly. But you don't need my product to take the point. The next time you're about to add the fourth tab to the admin panel, ask whether you're solving a data-access problem by writing more application code, and whether there's a version where the people who need the data can just get it, safely, without you in the loop.
The honest caveat
Admin panels aren't all debt. The actions — refunding, impersonating, flipping flags, anything that writes — genuinely benefit from a controlled UI with guardrails and an audit trail. I'm not arguing you should hand out write access to production through a query box. That part of the panel is earning its keep.
It's the read half that's the bad deal. The endless lookups, the views, the filters, the "can you add a column to that table" tickets. That half is a worse version of a query, dressed up as an app, that you'll maintain until the company dies. Build the actions. Stop hand-building the lookups.