How to Build a Client Portal: Files, Status, Invoices and Permissions

How to build a client portal where clients see project status, files, requests and invoices, with the permissions, data and security choices that keep it safe.

Mythex Team · 2026-09-29 · 7 min read

A client portal is a private area where each of your clients logs in to see their project status, shared files, open requests and invoices. To build one, define exactly what a client needs to see in the first ten seconds, model clients, projects and files so that every record belongs to one client, enforce on the server that clients only ever see their own records, and keep uploads in private storage. The feature list can stay short; getting permissions right is what matters.

Why businesses build client portals

Portals usually replace a pile of email threads, shared folders and "what's the status?" messages. Agencies, accountants, consultants, builders, studios and service businesses all use them. A good portal:

Answers the status question before the client asks it.
Puts files in one place, with the latest version obvious.
Gives requests a proper home instead of scattered emails.
Makes you look organised, which matters for retention and referrals.

If you have one or two clients and nothing sensitive, a shared document or folder may be enough. A portal is worth building when you have many clients, repeat work, or information clients should not see about each other.

What a client portal needs

Part	What the client sees	What you see
Login	Their own account	All clients and their users
Overview	Current status, next milestone, what is waiting on them	Every project's status at a glance
Files	Documents and deliverables shared with them; their uploads	All files, by client and project
Requests	A form to ask for something, and the status of past requests	A queue of requests to assign and answer
Messages or updates	A timeline of updates on their project	The same timeline, plus internal notes they cannot see
Invoices	What they owe and what they have paid, with a pay link	Billing status across clients
Approvals	Approve a design, quote or deliverable	Who approved what, and when

Start with login, overview, files and requests. Add invoices, approvals and messaging when clients actually need them.

The data

A typical portal has: clients (companies), client users (people who log in, belonging to one client), your team members, projects (belonging to one client), milestones or status updates, files (belonging to a project), requests, and optionally invoices. The key design rule: every record should trace back to exactly one client. That makes permissions straightforward to enforce and to check.

Permissions

Write these down and test them:

A client user sees only projects, files, requests and invoices belonging to their client.
Internal notes are never shown to clients.
Team members see the clients they are assigned to, or all clients if you are small.
File links are private and time-limited, not public URLs anyone could share or guess.
Removing a client user immediately removes their access.

The checks must happen on the server. A portal that loads all clients' data and filters it in the browser is not private.

Decisions and trade-offs

Clients log in rarely, so they forget passwords. Magic links (a sign-in link sent by email) or single sign-on with an account they already use often work better than passwords for portals. Whichever you choose, invite clients from your side rather than letting anyone sign up. Our guide on adding login to your app compares the options.

One portal or one per client

One app with a client list is easier to maintain than a separate site per client. You can still give each client their own branded feel — their logo, their project names — within the same app.

Files

Use proper file storage rather than saving uploads to the server's own disk, set a maximum file size, restrict file types if you can, and serve files only to users who pass the permission check. Decide how versions work: overwrite, or keep history.

Invoices and payments

You can show invoices from your accounting tool, generate simple invoices in the portal, or link to a hosted payment page. Building a full invoicing system is a project of its own — see how to build an invoicing app. For a portal, showing invoice status and a "Pay now" link to a hosted checkout is usually enough.

Integrations

Many portals pull status from tools you already use — a project tracker, a CRM or accounting software — rather than asking you to update two places. Integrations save time but add setup and maintenance. If your team already lives in a CRM, consider building the portal on top of the same data.

A first prompt for an AI builder

Build a client portal for Northlight, a small web design agency. Clients are companies; each has one or more client users who log in. Client users see only their own company's projects. For each project: current status (Discovery, Design, Build, Review, Live), next milestone with date, a files area where both sides can upload (PDF, images, ZIP, max 50 MB) and download, a request form (title, details, priority) with a list of their past requests and status, and a timeline of updates. Agency staff see an admin area with all clients, can change project status, post updates, add internal notes that clients never see, and answer requests. Enforce all access rules on the server. Save data in a database and files in private file storage with time-limited download links. Placeholder login for now — we will add real authentication next. Clean, professional design that works on phones.

Build in steps: data and admin first, then the client view, then real login, then files, then extras. How to write prompts for AI app builders has more patterns.

Build steps

List what a client needs to see first, and what they currently email you about.
Design the data so every record belongs to one client.
Build the admin view and enter one real client's data.
Build the client view for that client.
Add real login with invitations from your side.
Add files in private storage with permission checks on download.
Test permissions: create two test clients and try every way to see the other's data — changing IDs in the URL, guessing file links, using an old invite.
Add requests and notifications by email.
Pilot with one or two friendly clients and ask what they still email you about.
Add invoices, approvals or integrations based on that feedback.

Common mistakes

Filtering in the browser instead of the server. The most serious portal bug: every client's data is downloaded, just hidden.
Public file URLs. A shared link that anyone can open defeats the portal.
Open sign-up. Clients should be invited, not able to create their own accounts and pick a company.
Too many features at launch. A portal clients do not understand gets ignored in favour of email.
Two sources of truth. If status lives in your project tool and the portal, one will be out of date. Pick one or sync them.
Forgetting offboarding. When a client's staff member leaves, their access must end.
Storing regulated data without the right protections. Health, legal or financial records may carry legal requirements you need to meet.

Costs and tools

The running costs are hosting, a database, file storage (which grows with the files you share), and an email provider for invitations and notifications. If you use a hosted login provider or payment provider, check their current pricing on their own site. Compared with per-seat portal software, your own portal's costs grow with usage rather than with the number of clients.

When a ready-made product is the better choice

Client portal software, and portal features built into accounting, legal or practice-management tools, can be the better choice when your industry has specific requirements — e-signatures with legal standing, regulated record-keeping, tax document exchange — or when your existing tool already includes a portal. Those products have already handled compliance and support. Build your own when your workflow does not fit generic portals, when you want the portal to match your brand and process exactly, or when per-client or per-seat pricing no longer makes sense for you.

Building it with Mythex

Mythex can build the portal in the prompt above: a client view, an admin view, requests and a timeline, with a dedicated Postgres database and file storage added when the app needs them. Client login is bring-your-own — Mythex accounts are for the people building the app, and you choose an auth approach for your clients that the agent wires in. Mythex has no built-in e-signature or invoicing product, so those are integrations or features you build. Use project secrets for any API keys, and the in-chat app tester to click through the client and admin flows before you publish.

The docs have a client portal use case and cover file storage and adding login. For a starting prompt, try the agency client portal template or browse app templates. Before inviting real clients, run through our security checklist for AI-built apps.

Questions

What is a client portal?

A client portal is a private, logged-in area where a business's clients can see the status of their work, exchange files, make requests and view invoices, instead of doing all of that over email. Each client sees only their own information.

What features should a client portal have?

Start with secure login, a status overview per project, a files area, and a way to send requests or messages. Invoices, approvals, e-signatures and scheduling can come later if clients actually need them.

Is it safe to build my own client portal?

It can be, if you enforce on the server that each client sees only their own records and files, use proper login, keep files in private storage, and test by trying to open another client's data. Regulated information such as health records needs extra care and may be better in a specialised product.

Can I build a client portal without code?

Yes. AI app builders and no-code tools can build a client portal from a description. You still need to be precise about who can see what, and test those rules carefully before inviting real clients.