Client portal checklist: 12 things clients expect to find

A client portal checklist starts with one rule: each client signs in and sees only their own work. Around that rule, clients expect twelve things: their own sign in, only their own projects, a clean way to join, status, milestones, updates, files, approvals, invoices, messages, notifications and control of their data. The table below lists all twelve and how the portal capability in OneCraft’s AI site builder builds each one.

The six things clients see

Status first. The first screen should answer the client’s first question: how far along is it? A card per project with its status and the next milestone does that in one glance, and a progress list of milestones with dates turns a vague job into a plan.

Updates instead of status emails. A short feed of updates, with room for client comments, replaces the weekly “any news?” email. Post little and often.

Files in one place. Drafts, drawings, contracts and photos belong next to the project, not scattered across email threads. Clients should be able to upload too, within a size limit.

Approvals with a record. Approve or Request changes, with a comment, gives you a dated record of what the client signed off. That record settles more disputes than any contract clause.

Invoices next to the work. A client who sees the invoice beside the finished milestone pays faster than one who digs it out of an inbox. A pay link removes the last step.

Messages that stay with the project. One conversation per project keeps decisions findable months later.

The six things clients assume

Their own sign in. Shared logins are not a portal. Current guidance is clear on the basics: NIST’s digital identity guidelines set a minimum of 15 characters for passwords used on their own, and OWASP’s authentication cheat sheet asks that sign in and reset pages answer with a generic message so they do not reveal which accounts exist.

Only their own work. This is the one that matters most. Access must be enforced where the data is stored, not by hiding links on the screen. In a Postgres database that means row level security: a rule on every table that returns a client’s rows only to that client and your staff. The row level security page explains how it works.

A clean way in. Invite each client with a personal link that adds them to their project once they sign in. Do not grant access because an email address matches; mistyped and shared mailboxes make that unsafe.

Notice of change. A notification when you post an update or need an approval saves clients from checking every day.

Control of their data. Australia’s 13 privacy principles cover how personal information is collected, used and disclosed, kept accurate, and made available to the person it is about. A portal should let clients see what is held about them and ask for it to be corrected, exported or deleted. The data export request page covers the export side.

Privacy and terms pages. Say what you collect, why, and how long you keep it, in your own words. How to write a privacy policy walks through it.

How OneCraft builds a portal

OneCraft’s AI agent builds a portal from its portal guide into the site’s own database. Projects, project members, invites, updates with comments, files, approvals, invoices and messages are tables, and every one is guarded by a membership check inside the database. Before the work can finish, the agent checks projects and files as an anonymous visitor (refused), as a signed in person who is not a member (refused) and as an admin. Files sit in a private bucket readable only through the site’s own rules, up to 25 MB each, and an app opens them from a short lived link.

There are limits to plan around. The site cannot email clients freely, so you send the invite link from your own email, using the Email button or Copy in the admin. There is no SMS and no push to phones; clients see changes in the notification bell. Payments run through Stripe only, on your own connected account. The website with its own database page explains where the data lives, and the Softr alternative page compares this approach with a portal built on a spreadsheet.

Before you invite the first client

1. Create a test client account and try to open another project’s page and files.
2. Reset the test client’s password from the sign in page.
3. Upload a large file and a small one.
4. Request an approval and respond to it as the client.
5. Pay a small test invoice and check it shows as paid.
6. Read your privacy page as a client would.