Client portals sound straightforward: give clients a place to log in and see their project status, reports, or documents. We built our visual AI development platform specifically to handle this use case, including the part that breaks most tools.
The complexity hides in one requirement: each client should see only their own data. Client A should never see Client B's projects, invoices, or files, even though both log into the same portal.
This is per-client data isolation. It is where many no-code tools and AI builders break down for non-coders. Tools like Retool, Lovable, Claude Code all require SQL knowledge (or an unhealthy trust in probabilistic AI!) to setup advanced role-based access controls. Some template-based tools do not support it at all.
In WeWeb, you configure data isolation visually. No SQL, no code, no developer. This guide walks through the complete build process.
Why Client Portals Need Role-Based Access
A client portal without proper access control is not just incomplete, it is a liability.
If Client A can access Client B's data (even accidentally), you have a data breach. For agencies handling confidential client work, financial firms managing portfolios, or healthcare providers with patient data, this is not a hypothetical risk.
Role-based access control for a client portal typically requires three things:
- Per-client data isolation: Each authenticated client sees only records associated with their account
- Staff vs client role separation: Your internal team sees all clients; clients see only themselves
- Read-only vs editable access: Clients may be able to view but not edit certain records
In code-based development, this is handled through database-level access control (Row Level Security in Postgres, policies in Supabase). In WeWeb, it works the same under the hood but users can handle it through visual data filters and role configuration in the editor.
What You're Building
A client portal in WeWeb typically includes:
- Client login page: Email/password or social login (Google, Microsoft, etc.)
- Client dashboard: Overview of their projects, reports, or status
- Detail views: Individual project pages, document lists, invoice history
- File access: Documents or reports filtered to the logged-in client
- Optional: messaging or comments: Client-to-staff communication within their portal
Your internal team sees a separate admin view with all clients visible and management tools available.
All of this is one WeWeb project with role-based visibility.
The Build Process
Step 1: Plan Your Data Model
Before opening WeWeb, plan your data model:
- Clients table: id, name, email, company, status
- Projects table: id, client_id, name, status, start_date, due_date
- Documents table: id, client_id, name, file_url, uploaded_at
- Users table: id, email, role (client | staff | admin), client_id (null for staff/admin)
The client_id field on the Users table is the key: it links each portal user to their specific client account. Every query that runs for a client user filters by current_user.client_id.
Step 2: Generate the Foundation with Our AI
Describe your portal to our AI:
"Build a client portal for a consulting agency. Clients log in and see their own projects, documents, and status updates. Staff see all clients. Admins can manage clients and portal settings. Data: clients table, projects table (linked to client), documents table (linked to client). Roles: client, staff, admin."
Our AI generates: UI pages for all three role types, WeWeb Tables schema matching your data model, authentication flows, role configuration, and basic data connections.
Step 3: Configure Per-Client Data Isolation
This is the critical step and, in WeWeb, it is a visual configuration.
In the Projects data source used on the client dashboard:
- Open the data source settings
- Add a filter:
client_id = current_user.client_id - This filter runs automatically when any client user loads the page — they see only their projects
In the Documents data source:
- Same pattern:
client_id = current_user.client_id - The document list page now shows only this client's files
In the Admin view:
- No filter: staff and admin roles see all records
- Set page access rule: only users with role
stafforadmincan access admin pages
That is the complete per-client data isolation. No SQL. No Row Level Security policies. Visual configuration.
For a deeper explanation of how role-based access works in WeWeb, see our complete RBAC guide for no-code apps.
Step 4: Configure the Role System
Define roles in WeWeb Tables:
- Add a
rolefield to the Users table (string type) - Values:
client,staff,admin - Default for new sign-ups:
client
Staff sign-up flow: Do not expose public sign-up for staff accounts. Staff accounts are created by an admin in the admin panel. Their role field is set to staff at creation.
Set page visibility per role:
- Client pages: visible when
user.role = client - Admin panel: visible when
user.role = staffORuser.role = admin - Individual client management pages: visible when
user.role = admin
Step 5: Design the Client Experience
The client's experience matters. A well-designed portal increases adoption and reduces the "where is my stuff?" support requests.
Client dashboard should show:
- Active projects with status indicators
- Recent documents or reports
- Any outstanding action items or approvals needed
Use WeWeb's visual editor to build this layout. Adjust spacing, typography, and branding to match your agency or the client's expectations. The design is fully customizable. You're not limited by template constraints.
Step 6: Set Up the Staff Admin View
Your internal team needs to:
- See all clients in a list
- Access any client's portal view for support purposes
- Upload documents and update project status on behalf of clients
- Manage user accounts (create, deactivate, reset passwords)
This is a separate section of pages in the same WeWeb project, accessible only to staff and admin roles.
Step 7: Deploy and Onboard
Deploy to your custom domain or a client-specific subdomain. Onboard clients with a simple invitation email (configurable through WeWeb's email workflow system).
For agencies managing many clients: the same portal scales to all of them. No per-user pricing means 50 clients or 500 clients costs the same $20/month base.
Where Other Tools Break Down
Most AI app builders like Lovable: Generates a good-looking portal quickly. Per-client data isolation requires Supabase Row Level Security (i.e. SQL-based policies that can get complicated for non-technical founders to configure when the project is complex). If you've already hit this wall with Lovable, the switch to WeWeb follows a clear path. Without proper RLS you fully understand, all clients can potentially see each other's data.
Retool: Strong internal tool builder, but requires SQL/JavaScript for data filtering. Also, having been designed for internal tools, not client-facing portals, the design constraints are obvious.
AI coding tools (Claude Code, Cursor, Codex): These tools can write a client portal very quickly (authentication, database schema, role logic, all of it!) But the output is code you own and must maintain. Per-client data isolation still requires configuring Supabase RLS policies or writing custom middleware. When something breaks (e.g. a client sees data they shouldn't or a role check fails) you are debugging code. For non-technical builders, the gap between "AI generated it" and "I understand it well enough to fix it" is where these tools stall. Not to mention that blindly trusting probabilistic AI to handle the security of your app without understanding the code it generated is optimistic at best.
Template-based tools (Softr, Glide): Some support basic client portals. Most do not support custom role hierarchies or per-client isolation beyond simple "user can see their own rows" patterns. Customization is limited by templates.
WeWeb: Under the hood, WeWeb follows web development best practices, while giving you the tools to secure your app visually. You can configure filters for per-client data isolation, set up role-based page access, and control what each user can see without writing code. And the UI is pixel-perfect: there are no template constraints to limit the brand style you want to convey to your customers.
Frequently Asked Questions
Can clients sign up themselves, or do I create their accounts? Both options are supported. You can enable self-registration (new sign-ups automatically get the client role) or create client accounts manually through the admin panel and invite them via email.
Can different clients see different features based on their plan? Yes. Add a plan field to the Clients table (e.g., basic, pro). Add visibility conditions on premium features: "show only when current_user.plan = pro." No code required.
Can I white-label the portal with the client's branding? WeWeb's visual editor gives you full control over colors, typography, logos, and layout. You can build a fully white-labeled portal that matches any client's brand.
What if I need to build separate portals for different clients with different structures? For significantly different portal structures, you would build separate WeWeb projects. For portals with the same structure but different branding or data, one project with role-based access and design theming handles it.
Does this work for HIPAA-compliant portals? WeWeb supports HIPAA-compliant architectures through self-hosting. Your data stays in your infrastructure; WeWeb is just the frontend layer. See our HIPAA no-code app builder guide for the full compliance picture.
Conclusion
Building a client portal with proper role-based access is achievable without code. The same approach works for building a SaaS product with multi-tenant isolation. The key is using a platform where per-client data isolation is visual configuration, not SQL.
In WeWeb, you configure data filters, role assignments, and page visibility through the editor. The result is a production-ready client portal where each client sees only what they should.