A client portal page: one link that holds the whole engagement
Three weeks into an engagement, everything you have produced is scattered. The scope is in an email, last month's report is in a different email, the dashboard link is in a Slack message that has rolled off the top, and the deck is in a shared drive nobody remembers the name of. Then the client asks where the thing is, and you spend twenty minutes being a search engine for your own work. A client portal page ends that: one page, one link, everything the engagement has produced, kept current.
Decide what the client should never have to ask for again
Usually the same six things: where we are, what is next, the deliverables so far, who to contact, the invoice, and the schedule. That list is the portal. The client-salesroom prompt below turns it into one page with a section per item.
Publish it once, at a link you choose
Publish the file and, on Pro, give it a slug with the client's name in it. Put a password on it if the engagement is confidential. That URL is now the answer to every “where do I find…” email for the length of the project.
Update the page, not the link
When the status changes, edit the page in place on Pro. Everyone who already has the link sees the new version — you never send a second URL, and there is never a stale copy circulating.
What a one-page client portal actually contains
It is an index, not an application. A short status line at the top — what phase we are in, what is next, when the next deliverable lands. Then links to the live things: this month's report, the dashboard, the shared documents, the recording of the last call. Then the boring but valuable part, which is who to contact about what.
That is a page, not a product. It is also exactly the kind of document an AI assistant writes well: give Claude or ChatGPT your notes and ask for a single self-contained HTML page with those sections, and you will have a first version in a minute. The starter prompts on our templates page cover this shape directly.
The discipline that makes it work is that the portal is the only thing you ever send. New report? It goes on the portal and you say so. New credential? Portal. The client learns one URL and stops asking you to resend things.
One URL that survives the whole engagement
A portal is only useful if it is stable. The client bookmarks it, pins it in their own Slack, or forwards it to a colleague who joins the project in month four — and every one of those breaks if the link changes when you update the content. In-place editing on a paid plan rewrites the page behind the same URL, so the portal is always current and the address never moves.
When the engagement produces a lot of separate pages, collections give you the other half of the pattern: each deliverable keeps its own link, and one collection link at host-html.com/c/your-name is the front door to all of them. Some people use the portal page as the narrative and the collection as the archive.
Custom slugs on a paid plan mean the URL can carry the client's name, which is a surprisingly large part of why a portal feels like a service rather than a folder.
Access, permanence and the boring reliability part
Most portals contain something commercially sensitive, so password protection on a paid plan is usually the right default. Be clear-eyed about the model: a published page is public at its URL until you turn a password on. If the content should never be world-readable, turn it on before you share the link, not after.
Reliability is the other thing a client link needs, and it is the part nobody thinks about until it fails. Pages serve from a dedicated content domain that is kept reputation-isolated from our main site, every publish is scanned for abuse, and pages run sandboxed under a strict content-security policy. That is what keeps a link opening on a client's locked-down corporate network instead of hitting a URL filter.
A portal is by definition a page that must not expire in the middle of an engagement. Publishing is free and a free page expires after 5 days, which makes the free tier a fine way to build and test the layout — but the real thing belongs on Pro at $12 a month, where the page lives forever and the link you gave the client in January still opens in December.
The shared folder against the portal page
| A Drive folder or a wall of links | One portal page | |
|---|---|---|
| What the client sees first | A file list sorted by date, with your naming conventions on display | A page you laid out, in the order you want it read |
| Access | Sharing settings, sign-in prompts, “request access” emails | A link that opens, or a password you gave them — no account either way |
| Keeping it current | Upload a new file, hope they open the right one | Edit in place on Pro; the link never changes |
| Several clients | One folder structure you have to police | One page per client, each at its own URL, none aware of the others |
| Six months later | Moved, renamed, or owned by whoever set it up | Still resolving, permanently on Pro; a free page comes down after 5 days |
What this needs from host-html
- Collections — When the engagement outgrows one page, group the pages behind a single /c/ link instead of sending ten.
- Password protection and in-place editing — The two Pro features a portal actually needs: it stays private, and it stays current at the same URL.
- The client-salesroom prompt — A starter prompt that lays out status, deliverables, contacts and next steps in one page.
- Collect a reply on the page — Approvals, feedback or a sign-off can be captured on the portal itself and read back in your responses dashboard.
Frequently asked questions
What is a client portal page?
It is a single hosted web page that acts as the front door to one engagement: current status, links to every deliverable, next milestone and contact details. The client keeps one URL instead of hunting through email for the last thing you sent.
How is this different from sending a folder of files?
A folder has no narrative and no state. A portal page tells the client where the project is, links the current version of everything, and updates in place, so nobody has to work out which of four attachments is the latest one.
Can I password-protect a client portal?
Yes, on a paid plan. Turn on password protection and the page asks for a passphrase before it renders. Do it before you share the link — until protection is on, a published page is readable by anyone who has the URL.
Do I need a new link every time I update the portal?
No. In-place editing on a paid plan rewrites the page behind the same URL, so bookmarks, pinned Slack messages and forwarded emails all keep working while the content changes underneath them.
Can I run a separate portal for each client?
Yes. Each portal is just another published page in your dashboard, with its own slug, its own password and its own analytics, so ten clients means ten pages and ten links rather than one crowded site.
Will the portal link still work in six months?
On a paid plan, yes — paid pages never expire. A free page expires automatically after 5 days, so the free tier is for building and testing the layout rather than for a link a client relies on mid-engagement.