Direct answer
Build a custom client portal when a named job repeats, more than one person must see the same state, and email or a spreadsheet cannot enforce who may read or change it. Do not build a portal as a prettier status page that nobody will open.
This is a scope decision, not a ranking claim and not a quote. Fees, milestones, and handover stay in a written proposal.
The constraint that actually shows up
Shared inboxes fail in three ways: nobody knows the current state, attachments live in six threads, and former staff still have the history. Portals fail the other way: empty dashboards, unused logins, and a build that copies email into a UI.
Write the jobs first. Typical honest jobs are: see open work, upload a file, approve a milestone, download a deliverable, or message a named owner. If you cannot name three jobs, you do not have a portal yet.
Access control is the product
OWASP’s access-control guidance is blunt: deny by default, check every request, and do not hard-code roles into the page. A portal that hides a button but still serves the JSON is not a portal.
Start with owner, member, and operator. Add a role only when a job would otherwise leak data. Log authorization events without storing secrets or raw files in the log line.
A practical sequence
Work in this order. Skip a step only if you already have a dated artifact for it.
- List the three jobs a client must finish without email
- Name who may see each object: firm, workspace, or record
- Decide login: invite-only accounts, not a public signup
- Prototype empty, error, and permission-denied states
- Ship the jobs before the analytics wallpaper
Mistakes that look like progress
These are common, expensive, and avoidable:
- Building a notification centre before the object model exists
- Copying a SaaS competitor’s nav instead of the jobs you run today
- Leaving files in personal Drive folders ‘until the portal is ready’
What to send if you want a senior review
Share the jobs, who must not see what, and whether you need a live walkthrough of a portal pattern. Related work at Kiwi: SaaS MVP design and development, with source you own at the agreed handover.
Submitting a request does not create an engagement. A senior practitioner replies within one business day.
Frequently asked questions
Is a client portal the same as a website?
No. A marketing website is for anonymous buyers. A portal is an authenticated workspace with object-level access control. They can share a design system; they should not share an index policy or a CMS.
Can we start with a shared Drive and upgrade later?
Yes, if the jobs are still informal. Move to a portal when you need audit, expiry of access, or a single current state. Do not migrate files until the permission model is written.
Will Kiwi show a portal demo?
Yes. Request a live walkthrough on the project-request form. We do not publish invented client results; we walk through the jobs, states, and ownership model.
Sources
- OWASP — Enforce access controls
- OWASP Cheat Sheet Series — Authorization
- Nielsen Norman Group — Usability 101
Figures cited above are drawn from the linked publications and are the responsibility of their sources; we date and scope them rather than presenting them as universal guarantees.