Do you need a client portal, or just a link for each thing? (2026)

Somewhere between the fifth and the fifteenth client, the same thought arrives: this is getting messy, I should set up a portal.

It is a reasonable instinct and it is usually answering the wrong problem. What is actually messy is your own side — files in four places, a naming scheme you invented twice, and no single view of what you have sent whom. A portal does fix that. It fixes it by adding software your client now has to have an account for, which means the cost lands on them and the benefit lands on you.

Sometimes that trade is right. It is worth being precise about when.

The two jobs hiding in one word

Job one: a place they return to. The client, three months later, wants the thing you gave them in March. They should be able to find it without messaging you. That is a real job and it is fundamentally about persistence and findability — one address that always has everything.

Job two: keeping clients apart. You have eleven clients. Each must see their own material and nothing else. This is access control, and it is a different problem: it needs the system to know who is asking.

Portal software sells these together because job two forces accounts, and once you have accounts, job one is nearly free. That bundling is sensible engineering. It is also why you cannot buy a small piece of it — you take the accounts whether or not you needed them.

The question is which job you actually have.

The test

Will the client go and look something up, unprompted, weeks later?

Be honest, because the answer is usually no. In most professional relationships the deliverable arrives, gets used, gets forwarded internally, and lives in the client's own systems from that moment. Nobody logs back into your portal to re-read the strategy deck. If they need it again, they search their email — and the thing they find is your message with your link in it.

If that is the shape of your work, a portal means: your client creates an account they will use twice, to visit a page they will not return to, so that you can feel organised. The organisation problem was yours. Solve it on your side.

If the answer is genuinely yes — an ongoing retainer where the client references past work weekly, a long engagement with many documents, a team on their end who all need the same material — then persistence is real value, and a portal earns its account.

What replaces it when you do not need one

The alternative is not "just email the files." It is one address per deliverable.

Each finished thing gets its own unguessable link. You send the link when the thing is done. There is no account on their side, nothing to remember, no password reset in six months. Each piece can carry its own controls — a password on the sensitive ones, an expiry on anything time-boxed, nothing on the rest.

Two things make this hold up better than it sounds:

The link stays the same when the file changes. This is the part that decides whether the approach survives revisions. If updating a deliverable means minting a fresh URL, you are back to "which link was the current one" — which is the mess you were trying to escape. When the address is a slot you replace the contents of, the link you sent in March is still correct in June.

You can make the index page yourself. If a particular client genuinely wants one place with everything, that place can be a page — a plain list of links, at its own private address, that you add a line to each time you deliver. It has no login because it does not need one: it is already behind an unguessable address. It is a portal in the sense that matters to them, and it is a file you edit.

What you give up is real and worth naming: nothing tracks who opened what across the whole relationship unless you look per-document, there is no self-service account for them to manage, and the index page is only current if you keep it current.

When to actually buy the software

Go get a real portal — and there are good ones — when any of these is true:

• You must prove who accessed what. Regulated work, legal discovery, anything where "we can see it was opened" has to survive scrutiny. A link tells you a page was opened, not by whom.
• You need to revoke one person, not the link. Someone leaves the client's team and must lose access while their colleagues keep it. That requires identities, which requires accounts.
• The client's team is large and rotating. Ten people who each need to self-serve, with new ones arriving, is exactly the case accounts were invented for.
• The material is genuinely a library. Not five deliverables — hundreds of documents, searched regularly.

If you are in one of those, the account friction is not friction, it is the product. Buy the thing built for it rather than assembling an approximation.

The version most people actually need

For a solo practice or a small studio, delivery usually looks like this: something gets finished, it goes to one or two people, they look at it, they act on it. The interval where it matters is days, not years.

For that shape, the whole apparatus of a portal is scaffolding around a moment that is over in a week. What that moment needs is for the thing to arrive cleanly, look right on whatever device they open it on, be private without being awkward, and still be correct after you fix the typo they spotted.

That is four links in four emails, and a page of links if they ask for one. It is worth trying that first, because it costs nothing to abandon — and if you outgrow it, the fact that you outgrew it will be obvious, and you will know exactly which of the four reasons above pushed you over.