How to Build a Client Portal (and What You Get When It Ships)

A client portal is the difference between a client asking you for a status update and a client finding it themselves. If you want to build a client portal this week, here is what you end up with when it works: your own address on your own domain, a login for each client, a rule that shows every client only their own rows, and an admin view where you see everything. Nothing else in this guide matters until those four things exist. Everything after it is polish.

What a client portal is, and what you end up with

A client portal is an external-facing, login-protected slice of your business data. It is not your project management tool, and it is not your website. It is the one place where the people paying you can see the status of what they bought without asking you.

That distinction decides the whole build. Internal tools serve your team, so they can be ugly and complicated. A portal serves people who did not ask to learn your systems, so it has to answer one question on the first screen: what do I need to do next.

Some teams call the same thing a customer portal, a client area, or a customer hub. The naming does not change the build. What you are shipping is:

• An address. A published URL on your domain, not a shared folder and not a third-party subpath.
• Logins. One identity per client, so the portal can tell who is asking.
• A visibility rule. Each row of data belongs to exactly one client, and the portal enforces that on every read.
• An admin view. The same dataset, seen from your side, without borrowing a client's login.

Prerequisites and expected result

Before you build anything, collect three inputs. If you cannot answer all three, stop and answer them first; each one is a place where portals get rebuilt from scratch.

1. The objects your clients care about. Orders, projects, files, invoices, appointments, tickets. These are the nouns the portal will show.
2. Where those objects live today. A spreadsheet, an invoicing tool, a CRM, or nothing yet. This decides whether you start in a built-in database or connect something you already run.
3. Who may see which row. Your side, their side, and any partner or subcontractor in between.

Expected result: a published portal where two different clients can log in and each sees a different, correct slice of the same dataset.

Out of scope for this guide: regulated-industry compliance review, two-way sync with an ERP or accounting system, and single sign-on policy enforcement. Those are covered in the last section.

Step 1: Decide what each client should see

The first step is not design. It is a table, and writing it is what stops the expensive rework later.

Define three roles before you define any page: you (everything), the client (only their rows), and any partner (only the rows you explicitly share). Two of the three are easy to implement and easy to verify. The third one is where permission bugs hide, so decide deliberately whether you need it at all.

If you want client portal examples before you commit, take two from your own book of business: the client who emails you for status, and the client who asks for the same file twice. Those two conversations define the minimum viable portal better than any feature list.

The shape of a finished portal: one dataset, two views, and the rule that connects them.

Step 2: Put the data behind a login

Two separate mechanisms do the work here, and confusing them is the most common way portals leak data.

Authentication answers "who is this". Authorization answers "which rows may they read". A portal with the first and not the second is worse than no portal, because every logged-in client now sees every other client's records. Retool's own walkthrough of this build makes the point concretely: after connecting a database table, the query has to be narrowed to the signed-in identity, expressed in their example as a filter matching the current user's email, before the table is safe to publish.

So there are two things to check at this step:

• Login is required for every page, not just the home screen. A single unguarded route exposes the same data as no login at all.
• Every read is filtered by identity. The rule belongs to the data layer, not to the page. Hiding a column in the interface is not a permission.

If your data already lives in a database, aim for one query per object that is always scoped to the current client. If it lives in a spreadsheet, migrate it into a real table first; a store of typed rows behind a form is what turns a tracker into an application.

Step 3: Build the client-facing pages

With the rules in place, the page build is short. Four screens cover most portals.

The first screen is status, not navigation. The client wants to know whether anything needs them. Put the current state at the top, then the exception, then the history. Softr's feature list for this category, which runs through onboarding, account management, communication, documents, projects, billing, reporting, and support, is a useful checklist of what may eventually live here. It is not a demand that all eight appear on day one.

The detail screen holds one project or order. Everything that belongs to that object lives here: timeline, files, messages, payment state. One object per screen keeps the permission rule easy to reason about.

The documents screen is a filtered list. Clients do not browse folders; they search for the thing you sent them. Sort by date, group by project, and make download the primary action.

The billing screen shows state, not history alone. Outstanding, paid, and upcoming is enough. Anything more detailed belongs in your accounting tool.

Step 4: Brand it and publish on your domain

The first screen a client sees is the login page, which is also the screen most teams forget to brand. Replace the placeholder name there, in the password reset email, and on the empty states. Retool's guide lists white-label design among the features a portal is expected to have, and the reason is commercial rather than aesthetic: a portal on someone else's domain reads like a workaround, while a portal on yours reads like part of the service.

Three things to finish before you call it built:

• Own the address. Publish on your domain or a subdomain of it.
• Replace every piece of test data. Demo rows in a client's portal cost more trust than a missing feature.
• Write the empty states. "No invoices yet" is a sentence, not a blank panel.

Verify the portal before you invite a client

Two accounts are the only reliable test. Log in as client A in one browser and as client B in another, then walk the list below. If you skip this and invite a real client first, you will discover permission bugs in front of the person paying you.

1. Client A sees A's rows on every screen, including detail pages opened by direct link.
2. Client B sees B's rows, and A's data appears nowhere, including in search, lists, exports, and error messages.
3. A new client with no records yet sees a sensible empty state instead of a blank screen or an error.
4. Password reset works end to end on a real mailbox.
5. The portal is usable on a phone, since that is where most clients will open it.
6. Your admin view is reachable only by your own login, and never from a client session.

Then run one more pass with a person who is not you. Any instruction that needs explaining in the portal is a missing sentence, not a user error.

Build a client portal with Atoms

Start with the work a client needs to complete: approve a deliverable, send a missing document, or track a support request. Specify the records, the owning client and the allowed actions before asking for screens. Your first acceptance test is still two client accounts plus an admin account; the interface alone cannot prove access control.

The three examples below use fictional businesses and synthetic records. They are demonstrations you can inspect and adapt, not customer outcome claims. Each case needs its own permission and workflow checks before a real client uses it.

Design agency: Northstar Client Room

A brand client opens the next deliverable, reviews the project timeline and sends an approval or revision request. The agency needs an admin overview across clients; the client needs only their own projects and files.

Try the live Northstar Client Room demo · Open this example in Atoms

Try this journey: sign in as client A, open a deliverable and send feedback; reload to check the saved status. Sign in as client B and try A's direct project and file links. Those requests must be denied rather than hidden only in the navigation.

Bookkeeping service: Harbor Ledger Desk

A business owner sees the missing documents for the current close, uploads a synthetic receipt and checks that it was received. The bookkeeping team sees the document queue across both clients.

Try the live Harbor Ledger Desk demo · Open this example in Atoms

Try this journey: upload a harmless sample document as one client, reload and check the received record. The other client must not be able to list or download that document. No banking connection or financial advice is implied by this demo.

Managed support: Relay Service Hub

A customer submits a ticket, follows its progress and reads a resolution. The support team assigns the ticket and changes its status without borrowing the customer's login.

Try the live Relay Service Hub demo · Open this example in Atoms

Try this journey: create a ticket, check its field validation, then update it from the admin view. The saved update must appear after the client reloads, while a second customer cannot read the ticket by ID.

Copy this client portal brief

Replace the bracketed fields with your own workflow. Use synthetic data for the first build.

Build a client portal for [business]. Clients need to [one core task].
Store [records and fields] in a persistent database. Each record belongs to
one client. Use real authentication and enforce ownership on the server
for lists, detail URLs, changes, exports and private file downloads.
Clients see and change only the actions allowed on their own records.
Admins see both clients and can [admin action].
Seed two fictional clients and one admin. Include validation, empty states,
mobile navigation and a clear next action on the first screen.
Verify a saved change after reload. Verify that client B cannot read or
change client A's record or file, including by direct URL and API request.
Report any backend or permission checks that could not be completed.

Build your client portal with Atoms: open the builder section and paste the brief. If your starting data is in a tracking sheet, use the spreadsheet-to-web-app field mapping checklist before the import.

What it costs, and when buying beats building

The money question is not "free versus paid". It is which costs you take on.

One concrete example of a premise: client-portal.io is a paid product that requires WordPress, and its own FAQ says so, including the workaround of running WordPress on a subdomain if your site is built on something else. That is a reasonable trade for a content-led business and a poor one if your stack is already a database-backed application. Softr, for its part, markets managed hosting, granular permissions, and claims of SOC 2 and GDPR alignment as product features, which is another way of saying those responsibilities are the vendor's rather than yours.

If neither your data nor your process is unusual, buying client portal software is usually the cheaper answer. The case for building is that your visibility rule is genuinely specific: you share one project with a client and a subcontractor, or your reporting needs a shape no template offers. A no code client portal built on a real database is what makes that affordable, because the cost of change stays in the brief rather than in a migration project.

When not to build your own portal

Four situations where building is the wrong call, regardless of how cheap the tooling gets.

Regulated data. Health, legal, financial, and education records carry retention, residency, and audit obligations. A vendor that already carries the certifications has done work you would otherwise have to commission.

Two-way sync with a system of record. If the portal must write back into an ERP or accounting package, the integration risk usually exceeds the interface work.

Enterprise access requirements. Mandatory SSO, session policy, and audit logs are procurement blockers, not features you can add later.

A handful of clients, once. If you have three clients and one project each, a well-organised shared drive solves the same problem for less effort. Build the portal when the relationship is long and repeating.

Conclusion

Do one thing today, before you open a builder: write the table of "who may see which row". That single artefact decides your database structure, your pages, and your test plan, and skipping it is why portal projects stall in month two.

Then build the four screens in order, verify with two accounts, and only then send an invitation. Start building in Atoms with the objects, fields, and access rules you just wrote down, review the first version, and publish it on your own domain once the two-account check passes.