The PingPanda admin dashboard v1 was exactly what you'd expect from an engineer who needed to ship: a server-rendered HTML table of recent events, three `<select>` dropdowns for filtering by tenant, category, and date range, and a basic pagination control. I built it in two hours, deployed it, and considered it 'done.'
Three weeks later, a support agent messaged me directly: a customer's monthly quota counter was showing 4,218 events consumed against a Free tier limit of 1,000, but the customer's account had no billable events in the logs. The agent needed to cross-reference the quota table, the event log, and the Stripe subscription record to diagnose the discrepancy.
The agent had three browser tabs open, the dashboard in one, Stripe in another, and a psql terminal in the third. They were hand-copying tenant IDs between windows. The resolution took 8 minutes. A fix that should have been visible immediately.
I watched the entire session over a screen share. The problem was not the data — it was all there, correctly stored in PostgreSQL. The problem was that the dashboard had been designed by someone who would use it slowly, with time, from a comfortable chair. It had not been designed for a person who was responsible for another person's money and was under time pressure.
The first change I made was not a feature. It was search. I replaced the three dropdown filters with a single full-text search bar backed by a PostgreSQL read replica, returning results in under 80ms. Agents could type a tenant email address and immediately see their full account state: quota usage, event count, subscription tier, and last 10 events — on one screen.
The second change came from a pattern I noticed: agents were navigating away from the dashboard to Stripe's dashboard to check subscription status, then navigating back. I embedded a `<StripeSubscriptionCard />` component directly into the tenant detail panel, fetching subscription metadata via Stripe's API server-side during the admin page render. One page load. One screen.
The third change was the command palette. I added `Cmd+K` with three prebuilt actions: 'Go to tenant', 'View quota history', and 'Reset usage counter (requires 2FA confirmation)'. The first two eliminated five navigation steps. The third one — which required confirming a second-factor auth code before executing — eliminated the last reason a support agent had to open a psql terminal.
After all three changes, average ticket resolution dropped to 2 minutes and 20 seconds. Direct production database mutations stopped entirely. The support agent told me in a follow-up message: 'This is the first internal tool I've actually wanted to use.'
That sentence is the right success criterion for an internal tool. Not 'does it expose all the data,' but 'does someone who wasn't involved in building it actually want to open it?' If the answer is no, it is not done. It is a liability wearing a UI.