Admin Dashboard
Build a real admin dashboard with live data tables, stats, filters, and actions that actually mutate data.
The route
6 steps to Done
- 01
Define admin scope and data
Decide exactly what the admin manages so the dashboard is concrete, not decorative.
Preview prompt + verify gate ▾ Hide ▴
Define the admin dashboard spec for this app. List: the entities admins manage (e.g. users, orders, content), the 4-6 stats that matter (with the exact query behind each), the table columns per entity, the row actions (view/edit/disable/delete) and what each changes in the database, and who counts as admin. Every stat and action must map to real data - no decorative metrics.
- ✓ Entities to manage are listed
- ✓ Each stat has a defined query
- ✓ Each row action states its database effect
- ✓ Admin access rule is defined
- 02
Build admin layout and access control
Stand up the admin shell and lock it down before adding data.
Preview prompt + verify gate ▾ Hide ▴
Create the admin dashboard layout and protect it. Requirements: an /admin route with sidebar or tab navigation for each managed entity; access restricted to admin users (route guard AND backend enforcement on every admin endpoint - non-admins get 403); a visible 'access denied' experience for non-admins; loading skeletons for the shell. State how a user becomes admin in this app (flag on the user record) and create one admin account for testing.
- ✓ Non-admin users cannot open /admin
- ✓ Admin API endpoints reject non-admins with 403
- ✓ A test admin account exists and works
- 03
Implement real stats cards
Stats must come from live queries so the dashboard tells the truth.
Preview prompt + verify gate ▾ Hide ▴
Implement the stats row with real data. Requirements: each stat card runs its defined database query (counts, sums, recent activity); a backend endpoint returns all stats in one call; loading skeletons while fetching; an error state if the endpoint fails; numbers formatted sensibly. Prove correctness: create/change one record and show the affected stat updating on refresh.
- ✓ Each stat matches a hand-checked database count
- ✓ Adding a record changes the relevant stat
- ✓ Loading and error states render properly
- 04
Build the data table with search and filters
The core admin surface: browse real records with search, filters, and pagination.
Preview prompt + verify gate ▾ Hide ▴
Implement the main data table. Requirements: rows come from a paginated backend endpoint (server-side pagination); search box filters by the key text fields; at least two filters (e.g. status, date range) applied server-side; column sorting on at least two columns; empty state when no results; loading state on every fetch; error state with retry. Show total result count.
- ✓ Search narrows results correctly
- ✓ Filters combine with search
- ✓ Pagination fetches new pages from the server
- ✓ Empty and error states display
- 05
Add working row actions
Admin actions must mutate the database and survive refresh.
Preview prompt + verify gate ▾ Hide ▴
Implement row actions on the table. Requirements: a detail view (drawer or page) showing the full record; edit with a validated form that persists changes; disable/enable or delete with a confirmation dialog; optimistic or refetch-based UI update after each action; visible success toast and error handling on failure. Every action must persist - verify by refreshing after each one.
- ✓ Edits persist after a full refresh
- ✓ Delete/disable asks for confirmation
- ✓ Failures show a visible error, and the row is not silently wrong
- 06
QA the dashboard end to end
Verify truthfulness: stats, tables, and actions must reflect the database exactly.
Preview prompt + verify gate ▾ Hide ▴
Run a full admin QA pass and report PASS/FAIL with evidence: stats match hand-checked queries; search+filter+pagination return correct sets; each row action persists after refresh; a non-admin is blocked from the UI and gets 403 from admin APIs; empty and error states render (test by clearing filters to nonsense and killing the network in devtools). Fix all failures and re-run.
- ✓ All stats verified against direct queries
- ✓ Actions persist across refresh
- ✓ Non-admin block verified at UI and API level
- ✓ All failures fixed and re-tested