Do You Actually Need a Client Portal Yet?

The short answer: you need one once you have more than ten active clients with ongoing deliverables, or one client who has asked where they can see all their files in one place. Below that threshold, email plus a shared Drive folder per client usually wins, and buying a portal early adds a subscription plus an adoption problem without removing any work.

This post is written by a company that would benefit from you buying one. The advice is still to wait until the threshold, because a portal nobody logs into is worse than no portal.

What a client portal actually is

A client portal is a private, login-protected area where your clients see only their own work: deliverables, invoices, messages, and project status in one place. It differs from a shared folder in one way that matters - a folder shows files, a portal shows state. The client does not just find the contract; they see that it is signed, that the invoice is paid, and that the current milestone is in review, without asking you.

That definition holds the whole decision. If your clients' recurring question is "where is the file," a folder solves it. If the recurring question is "where are we," only a portal does.

The two signals that mean yes

More than ten active clients with ongoing deliverables.

The number matters less than the word "ongoing." Ten one-off projects do not create the problem. Ten relationships where things arrive, get reviewed, and come back do, because the coordination cost scales with the number of open loops rather than the number of clients.

A client has asked where they can see everything in one place.

This is the stronger of the two, and it only takes one. When a client asks, you have already lost the argument that email is fine. They are telling you the current arrangement costs them something.

Three things that look like the threshold but are not

"We send a lot of files." File volume is a storage problem, not a portal problem. A shared Drive folder per client handles it, and it is free. Portals earn their cost through status visibility and reduced back-and-forth, not through file transfer.

"Our inbox is a mess." Usually true, usually not solved by a portal. If the mess is internal coordination, the fix is internal. Adding a client-facing system on top of a disorganised process gives clients a window onto the disorganisation.

"It looks more professional." It does. That is a marketing reason, and it is legitimate for some businesses. But it does not survive the adoption test below, and a half-used portal looks worse than a well-run email thread.

The adoption test

Before you buy anything, answer this: will your clients actually log in?

The best portal is the one clients log into. That sentence sounds obvious and it kills most portal projects. A portal your clients ignore does not reduce your email volume, it adds a second place you have to update.

Two things predict adoption.

Frequency. If a client needs something from you weekly, they will learn a portal. Monthly or less, and they will email you instead because it is faster than remembering a password.

Whether it replaces something or adds to it. If the portal is where invoices live and where they pay and where project status is, it replaces things. If it is a file mirror alongside your existing email flow, it is an addition and it will be ignored.

A cheap way to test this: pick your most engaged client, set up a free tier, and run one real engagement through it. Adoption matters more than features, and one real client tells you more than a month of comparison shopping.

If you are below the threshold

Here is the setup that works and costs nothing.

A shared Drive or Dropbox folder per client, with a consistent internal structure. Deliverables, working files, invoices. Shared once, at the start, with edit permissions for them on one subfolder only.

A single email thread per project, not per topic. Threads fragment when people start new ones, so establish the convention early and reply to it yourself.

A status update on a schedule, sent whether or not there is news. Most "where are we on this" emails are anxiety rather than genuine requests, and a predictable Friday update removes them.

This holds to roughly ten active clients. Past that, the coordination overhead of maintaining it manually exceeds the cost of software.

The math behind the threshold: each active client generates a standing trickle of status questions, file requests, and invoice lookups. At five clients that is perhaps twenty minutes a week. At fifteen it is a part-time job spread across the team in two-minute fragments, which is worse, because nobody ever budgets for it and it interrupts work that is actually billable. The portal does not eliminate those questions - it moves them to a place clients answer for themselves.

If you are above the threshold

The decision then splits by one question: are you paying per client?

Flat-fee platforms charge a fixed rate regardless of how many clients you add - SuiteDash at $19 a month, HoneyBook Starter, Agiled's free tier. Per-client platforms scale with your client count, which means each new client makes the software more expensive at the moment it should be paying for itself.

Copilot's Starter caps at 50 clients for $39 a month, and custom domain support requires the Advanced plan at $149 a month. Monday Standard runs $864 a year at five clients and crosses $1,700 at thirty.

Neither model is wrong. But you should know which one you are on before you sign, and you should model your bill at three times your current client count.

The two things to check before you commit

Where white-label and custom domain sit. They are almost never on the entry tier that the marketing page advertises, and they are almost always what a client-facing portal actually needs. HoneyBook shows its own branding on every document with no custom domain option at any tier.

Whether any client might ever need compliance. If one of your clients could plausibly require a BAA, SOC 2 report or data residency guarantee, that narrows the list dramatically and it is much cheaper to know now. Most of the popular tools are not standard HIPAA configurations.

A five-minute decision checklist

Answer these in order and stop at the first clear no.

1. Do you have more than ten clients with work in flight right now, or has a client asked for one place to see everything? If neither, stop - the free setup below is your answer.
2. Will the portal replace at least two things clients currently email you about, rather than sit alongside them? If it only adds, it will be ignored.
3. Does a typical client need something from you at least every two weeks? Less often and they will not remember the login.
4. Is white-label or a custom domain on the tier you would actually pay for, not two tiers up?
5. Could any client you want within three years require a BAA, a SOC 2 report, or data residency? If yes, shortlist for that first and pick an interface second.

The honest summary

Under ten ongoing clients and nobody has asked: do not buy a portal. Set up the folder structure and the standing update.

Over ten, or someone has asked: buy the cheapest flat-fee option that has white-label on the tier you will actually be on, and run one client through it before rolling it out.

Past the point where per-client pricing hurts, or where a client's compliance requirements rule out the shortlist: that is when owning the thing starts to make more sense than renting it.

Butterbase is for that last case. Fork a production-ready client portal, run it as your own, self-hosted where the engagement requires it. Client isolation is enforced in Postgres rather than in a pricing tier, so adding clients does not add cost. If you are not there yet, the folder structure is genuinely fine - come back when someone asks. Related reading: What a Client Portal Actually Costs at 5, 20 and 50 Clients.

Frequently asked questions