Add an Admin Dashboard to Any AI-Built Web App

Start here

This guide adds an admin to an app you already have. Your app should already let people sign up and sign in, and it should already store the data you want an admin to manage. If sign-in is not working yet, add it first and come back.

Add User Authentication to Any Website with Supabase

Builds sign up, login, sessions, and protected areas with Supabase.

/video/add-user-authentication-supabase

Add User Authentication to Any Website with Firebase

The same sign up, login and protected areas using Firebase instead.

/video/add-user-authentication-firebase

Decide What Your Admin Will Manage

An admin area is only useful if it manages the records your project actually has. Pick the one or two that would save you the most time today.

Common things an admin manages

People who signed up

See who has an account and handle the few account tasks your app needs.

Bookings and appointments

See what is coming up and mark each one confirmed, completed or cancelled.

Orders and payments

Check what was ordered and move each order through its statuses.

Form submissions and messages

Read what came in and mark it handled so nothing gets answered twice.

Products and listings

Add, edit, hide or publish the items your app puts in front of visitors.

Posts and uploaded content

Review what users submitted and approve, edit or take down what needs it.

Your app may have something none of these describe. That is fine — the next step asks you for it in your own words, and the workflow stays the same either way.

Plan the Admin Area

Plan the Admin Area

Tell AI what the admin needs to manage and let it inspect the existing app before changing anything.

I want to add an admin area to this existing web app. What the admin should manage: {{ADMIN_PURPOSE}} What the admin should be able to do: {{ADMIN_ACTIONS}} What the app already has: {{EXISTING_SETUP}} Do not modify any files in this task. Inspect the project first and report what is actually there: - The framework and project type - The authentication system users sign in with today - Where the app's data lives: database, backend service or API - Whether any admin role, permission or admin-only code already exists - How access is enforced today: frontend checks, server-side checks, database rules, middleware or API authorization - The existing records that match what I want the admin to manage - The pages, components and data flows that adding an admin area would touch Do not print secrets, API keys or private credentials. Then recommend the smallest admin setup that fits this specific project. Rules for the recommendation: - One admin role only: normal user or admin. No teams, organizations, moderators or permission matrices. - Admin status must live somewhere a signed-in user cannot change about themselves - Reuse the authentication the app already has. Do not add a second login system. - Limit the first version to the 2-4 most useful admin screens - Include only the actions I asked for above - Do not add charts or statistics unless a number is genuinely useful for running this app Finish with these sections: Current Authentication How users sign in today. Current Admin Setup Any role or permission logic that already exists, or none. Recommended Admin Role Model Where admin status will be stored, and why a normal user cannot give it to themselves. Recommended Admin Area The route and the 2-4 screens. Admin Capabilities Exactly what the admin will be able to do. Security Requirements Every place authorization has to be enforced, including the data and server layer. Implementation Plan The smallest set of changes, in order. Missing Prerequisites Anything that has to exist before we start, or none. Do not start implementing. Wait for my approval.

What should the admin manage?

Users, bookings, orders, submissions, products, posts...

What should the admin be able to do?

What does the app already have?

Read the plan before you approve it. If it proposes screens you would never open, say so and ask for a smaller version.

NOTE

Start with the smallest admin area that solves the real need. More tools can be added later.

Add Real Admin Authorization

Use the app's existing sign-in — do not create a second login system for admins. This is the step that decides whether the admin area is actually protected. The dashboard itself comes later.

Add Admin Authorization

Adds admin permission on top of the sign-in you already have, and enforces it where the request actually lands.

Add admin authorization to this app, using the plan we just approved. Reuse the existing authentication. Do not create a second login system. There are exactly two kinds of account: normal user and admin. No teams, organizations, moderators, editors or permission levels beyond those two. Where admin status must live: - Somewhere the signed-in user cannot change about themselves - Not in localStorage, sessionStorage, a cookie the browser can edit, or any other client-side state - Not in a field the user's own account is allowed to update, through the app or through a direct API call - If the project's database has row-level security rules, for example Supabase, the rule protecting that field must reject a normal user who tries to set it on their own row What has to be protected: - The admin route itself - Every request that reads admin-only data - Every request that performs an admin action - Any API endpoint or server function the admin area will call Where the check has to happen: - On the trusted side: the server, the API route, the database rules, or the server-side middleware this project already uses - A check in browser code is for the interface only. It must never be the only thing between a normal user and admin data. - Typing the admin URL directly, or replaying the same request by hand, must be refused in exactly the same way Never: - Put a service-role key, admin API key or any other secret key in browser code - Turn off the database's security rules to make something work - Give every authenticated user admin access - Make admin-only data publicly readable Keep the implementation as small as possible. Do not build the admin interface yet. When you are done, tell me: 1. How an admin is identified 2. Every place authorization is enforced 3. Exactly how I grant admin to an account, and how I remove it again 4. What a normal user gets back if they request admin data directly Run the project's tests and production build. Finish with: Admin access: SECURE / NEEDS REVIEW

Create the First Admin Account

The first admin should be granted access through a trusted setup method — not through normal self-service sign-up.

Sign up in your app with the account you want to be the admin Use the trusted method from your authorization plan to mark that one account as an admin Sign out and sign back in so the app picks up the change Sign up a second, ordinary account as well — you will need it to test with

IMPORTANT

There must be no button, form, setting or signup option inside the app that lets an account make itself an admin, and admin status must never be something ordinary editable client data can change.

Check the Admin Route Directly

Find the admin route in your plan and keep it handy. Opening it by hand, signed in as an ordinary user, is how you prove the area is protected. Many apps use a route such as the one below, but use the one your project actually created.

/admin

Example admin route

IMPORTANT

Hiding an Admin button is user experience. Rejecting an unauthorized request is security. A normal user who opens that route by hand, or calls an admin request directly, has to be refused either way.

Build Only the Screens You Approved

Now build the admin area from the plan. Keep it fast, clear and consistent with the existing app rather than designing a separate product.

Build the Admin Area

Builds the approved admin screens against real data, behind the authorization you just added.

Build the admin area we approved in the plan. Build only the screens from that plan. Do not add screens we did not agree on. Requirements: - Put the admin area behind the authorization we just added - Show the admin entry point only to admins, wherever the plan puts it - Use the app's existing design, components and layout so the admin area looks like the same product - Read real data from the app's existing database or backend - Show only the fields that are genuinely useful for each record - Make long lists easy to scan, with the most relevant records first - Provide a clear loading state - Provide a useful empty state that explains what will appear there - Handle errors instead of showing a blank screen - Make it usable on a phone screen Do not: - Invent statistics, placeholder customers or sample records - Add charts for decoration - Show private fields just because they exist in the database - Add a second database or unnecessary packages - Change the public website or the normal user experience - Build the admin actions yet. This task is the screens and the data they show. Preserve everything the app already does. Run the production build afterward. When you are done, list: - The screens you added - The files you changed - Anything I still have to configure by hand Finish with: Admin area: READY / NOT READY

Open It as the Admin

Sign in with your admin account and check the basics before going further.

The admin entry point appears where you planned it

The admin area opens

The screens show real data from your app, not placeholders

The public site and the normal user pages look unchanged

Turn On Only the Actions You Chose

Admin reads and admin actions both need authorization. Actions that create, edit, delete or change data need the same trusted-side protection as the admin-only data itself.

Connect the Admin Actions

Adds the approved admin actions and proves a normal user's request is refused, not just hidden.

Add the admin actions we approved in the plan, and nothing else. Build only those actions. Do not add create, edit or delete for records we did not agree on. Every action has to be protected where the request actually lands: - The server, API route, server function or database rule that performs the change must confirm the caller is an admin - Hiding the button from a normal user is not protection - The same action, called directly using an ordinary user's session, must be refused - The same action, called with no session at all, must be refused For each action: - Validate the values being saved, including which statuses are allowed - Show clear success and failure feedback - Stop a double click from running the action twice - Ask for confirmation before anything destructive - Never report success when the operation actually failed Do not: - Use a service-role key, admin API key or any other secret key in browser code - Loosen or disable database security rules to make an action work - Add bulk operations, exports, imports or other admin features we did not plan Then prove the protection is real. For each action, show me the exact place an ordinary user's request is rejected — the server check, the API check or the database rule — not the place the button is hidden. Run the production build afterward. When you are done, list: - Each action you added - Where each one is authorized - The files you changed

NOTE

Start with only the actions the admin actually needs. Add destructive actions such as Delete later if they are genuinely necessary.

Use Two Real Accounts

This is the test that proves the admin area is actually protected, and it needs two accounts, not one.

Sign in with your admin account in your normal browser window Open a private or incognito window and sign in with the ordinary account Keep both windows open so you can switch between them

Test the Admin Account

In the admin window, confirm all of this works:

The admin entry point appears where you planned it

The admin area opens

The screens show the real records you expected

At least one admin action completes successfully

Refreshing the page keeps you inside the admin area

Signing out and back in still works

Test the Normal User

Now switch to the ordinary account. Every one of these has to be blocked:

No admin-only entry point appears in the normal user interface

Typing the admin URL by hand does not open the admin area

No admin-only data comes back, even if the page is reached another way

The protected admin action is refused

Nothing in the app lets this account turn itself into an admin

The normal parts of the app still work exactly as before

Test Logged Out

Sign out completely. A visitor with no account has to be blocked the same way.

The admin URL does not open

No admin data comes back

The public pages still work normally

Run the Final Check

Final Admin Security Check

Checks all three account states end to end and reports whether the admin area is ready.

Run a final check on the admin area we just built. Test all three account states: 1. Logged out 2. Normal signed-in user 3. Admin Authorization - A logged-out visitor cannot open the admin area - A normal user cannot open the admin area, including by typing the URL - A normal user cannot read admin-only data by calling the request directly - A normal user cannot run an admin action by calling it directly - A normal user cannot turn their own account into an admin, through the app or through a direct request - The admin can reach only the admin functionality we planned Data and interface - Admin screens read real data from the app's own database or backend - Private fields are not exposed unnecessarily - Loading, empty and error states behave correctly Admin actions - Each approved action works - Values are validated - Destructive actions ask for confirmation - A failed operation never reports success - Repeated clicks do not run an action twice The rest of the app - Normal user functionality is unchanged - Public pages still work - Sign-in and sign-out still work - The layout still works on a phone - No secret or service-role key is reachable from browser code - The production build succeeds Do not weaken any authorization rule to make a check pass. Do not deploy anything. Finish with: Admin area: READY / NOT READY If NOT READY, list only what is actually blocking it.