The 'who can see what' problem: adding user permissions to your AI-built app

The moment your AI-built app stops being just for you is the moment permissions become a real problem. Up until then, every page shows everything. Every list shows every row. Every button works for everybody. It’s a single-player app pretending to be multi-player.

Then you add your first teammate, or your first customer, or your first beta tester — and they see a thing they shouldn’t see. Maybe it’s their teammate’s salary. Maybe it’s a draft that wasn’t ready. Maybe it’s the admin settings, accidentally exposed.

This is the “who can see what” problem, and it’s the single biggest thing non-technical builders get wrong when shipping an AI app builder project. The good news: you don’t need to become a security expert to solve it. You just need a clear way to talk to your AI builder about it.

Why your AI-built app starts permissive

When you describe an app to an AI builder — “I want a CRM where I can add clients and notes” — the builder optimizes for one thing: making it work for the person describing it. The default app is “everyone who’s logged in can see everything.” This is fine for a personal tool. It’s a disaster the moment a second user appears.

This isn’t a bug in the AI app builder. It’s the natural result of you not telling it who’s allowed to see what. The builder has no idea your client list is sensitive, or that “Notes” might contain things you don’t want clients seeing. You have to say so.

The three questions to ask before adding a second user

Before you invite anyone, ask yourself three things. Write the answers down — you’ll feed them to your AI builder in the next step.

1. Who are the roles?

Not the people — the categories. Most apps have somewhere between two and four. For a freelancer portal: “Me” and “Client.” For an internal tool: “Admin,” “Manager,” “Team member.” For a community app: “Moderator,” “Member,” “Guest.” Resist the urge to go past four roles early. Every role doubles the rules you have to keep track of.

2. For each role, what can they see?

Go through every page in your app, mentally. For each one, ask: should a Client see this page at all? Should they see all the data on it, or only their own? Should they see the page but with some fields hidden?

The simplest pattern: owners see everything; everyone else sees only what they were explicitly given access to. This works for 80% of apps without much customization.

3. For each role, what can they do?

Same exercise, but for buttons and actions. Can a Member delete a project? Can a Client edit their profile but not their plan? Can a Manager invite new people? Most non-technical builders forget this step entirely and end up with apps where any logged-in user can delete the whole database with one button click.

Talking to your AI builder about permissions

Once you have answers, the prompt to your AI builder writes itself. It looks like this:

Update this app to support two roles: Owner and Client.

Owners can see all clients, all projects, and all invoices. Owners can create, edit, and delete anything.

Clients can only see their own projects and their own invoices. They cannot see the client list, the team page, or the settings page. They can view their projects but cannot edit them. They can view and pay their own invoices.

When a Client is logged in, hide the navigation links to Settings and Team. If a Client tries to visit those pages by URL, redirect them to their dashboard.

Three things matter in that prompt:

Be specific by page and action. “Clients can see their projects” is vague. “Clients can view but not edit their own projects on the /projects page” is something an AI builder can actually implement.
Say what happens to the nav. Hiding the link is not the same as blocking the page. You want both.
Cover the URL-typing case. Otherwise a curious user can paste /admin into their browser bar and walk right in.

The four mistakes I see every week

After watching a lot of builders ship their first multi-user app, the same mistakes show up:

Hiding the button is not hiding the data. If you tell your AI builder to “hide the delete button for Clients,” the button disappears from the screen. But the underlying delete operation still works if someone figures out how to call it. The fix: also tell the builder to “reject delete requests from non-Owner accounts on the backend.” If the builder doesn’t know what “backend” means in your app, ask it to “block the action server-side, not just hide the button.”

One role for two jobs. People conflate “the people who pay” with “the people who use the app.” A Client paying you for work and a Client-employee using the dashboard you built for that client are not the same role. If you mix them, you’ll spend the next month patching one-off rules. Two roles. Always.

Letting users invite users from day one. It’s tempting to add “Invite a teammate” right away. Don’t. For your first 10 users, invite them yourself, by hand, from an admin panel only you can see. Self-serve invites are an entire category of permission rules (who can invite whom? what role do invitees get? can they invite others?). Wait until you actually need it.

Trusting what the AI builder says without checking. AI builders will tell you, confidently, that permissions are set up. They might be. They might not be. Always test by logging in as a non-owner and trying to do bad things: click delete buttons, paste in admin URLs, edit fields you shouldn’t be able to edit. If anything works that shouldn’t, ask the builder to fix it specifically.

A quick checklist before you invite anyone

Before you send that first invite to a second user, run through this:

I can list the roles in my app on one hand.
For each role, I know which pages they should see and which they shouldn’t.
I have logged in as a non-owner and confirmed the wrong pages are hidden.
I have tried pasting an admin URL into the browser as a non-owner and gotten blocked.
I have tried clicking delete or edit buttons that should be off-limits and gotten blocked.
If something goes wrong, I have a way to remove a user’s access fast.

If any of those bullets don’t pass, that’s the next conversation with your AI builder — before you send the invite, not after.

The one mindset shift that helps

Building permissions for a multi-user app is mostly about imagining you are a slightly nosy version of your worst-behaved user. Not malicious — just curious. They’ll click things. They’ll paste URLs. They’ll try to see what’s on the “Settings” page they noticed in your screenshot.

Your job — and your AI builder’s job — is to make sure that when they look, the answer is consistent: either they can see it because it’s their data, or they can’t see it because it isn’t. No edges. No accidentally exposed admin pages. No “I forgot that page existed.”

Most builders don’t think about permissions until something embarrassing happens. The good news: spending 20 minutes thinking about roles before you ship saves you the 20 hours of fixing it later, plus the email you don’t want to write to the customer who saw the wrong thing.

Building something with a multi-user side to it? Next time you sit down with your AI app builder, start the session by listing the roles in your app out loud. It’s the easiest five-minute habit to build, and it’ll catch most of the worst mistakes before they happen.