✦ Integration
Client portal software: what to include and what to leave out
Client portal software succeeds when it does two or three things customers actually want and does them well - not when it tries to mirror everything your staff can see internally. Scope creep, not technology, is what usually sinks these projects.
Haystak · 11 August 2026 · Updated 11 August 2026 · 7 min read
Client portal software gives your customers a secure, logged-in area to check order status, download documents, or message you directly, instead of phoning or emailing to ask. Built well, it removes a steady trickle of "just checking" enquiries from your team's inbox.
Built badly, it becomes an ever-growing second front end that tries to replicate your entire internal system for external users, and never quite gets finished. The difference almost always comes down to scope, not technical skill.
Start from what customers actually check
Before designing anything, look at what customers currently phone or email you to ask. It's rarely more than a handful of things: where's my order, can I see that invoice again, has my document been approved, can I message someone about this job. A portal that answers those well beats one that tries to expose every screen your staff use.
- Order or job status - a simple, current answer to "where are we", pulled from the system that already holds it.
- Documents - invoices, certificates, reports, contracts, available to download without asking.
- Messaging or requests - a way to raise something without a phone call, logged and traceable.
- Account details - the minimum needed for the customer to keep their own information current, not a full copy of their CRM record.
Anything past this list should earn its place with a clear reason, not be added because it was technically easy to expose from the underlying database.
Why scope creep is the real risk
A portal is not a project with a natural edge. Once customers can log in, someone will ask for one more report, one more filter, one more self-service action - each reasonable on its own, each adding a permission rule, a test case, and a way for the wrong person to see the wrong thing.
The way to keep this under control is the same discipline we'd apply to any custom web application: agree the first version's boundary in writing, ship it, watch what customers actually use, and add the next feature because the data says so rather than because it was requested loudest.
Access control: who sees what
This is where a portal differs most from an internal system. Internally, most staff can see most things, and mistakes are corrected in-house. Externally, a customer seeing another customer's invoice, even briefly, is a data breach - not an inconvenience.
| Control | Why it matters |
|---|---|
| Row-level filtering by account | Every query must be scoped to the logged-in customer's own records, with no exceptions in the code path |
| Role separation within an account | A junior contact and the account owner may need different views of the same customer's data |
| Session timeouts and secure login | Portals are internet-facing, so they need the same login hygiene as internet banking - not an afterthought |
| Audit logging | A record of who viewed or downloaded what, useful for both security and answering customer disputes |
Testing access control properly means actively trying to see another customer's data with a valid but different login, not just checking the main path works. This is one area we don't shortcut.
Document sharing without creating a second filing system
The temptation with document sharing is to build a portal-specific document store. It's usually a mistake. The better pattern is to make the portal a window onto documents that already live in your finance system, document management tool, or project system, with the portal reading and displaying rather than duplicating and storing.
- 01Identify where each document type already lives (invoices in accounting software, certificates in a project system, and so on).
- 02Build the portal to fetch and display from those sources via API integration rather than copying files across.
- 03Keep one source of truth per document, so a correction made internally is instantly reflected for the customer too.
UK GDPR considerations for a client portal
A client portal is, by definition, a system that holds and displays personal and often commercially sensitive data to people outside your organisation, which means UK GDPR applies in full. The ICO's guidance on security is the right starting reference, and a few practical points come up in almost every portal build.
- Data minimisation - only show a customer what they need for the purpose of the portal, not their entire record.
- Retention - decide how long documents and messages stay visible, and build that into the system rather than leaving everything indefinitely.
- Right of access and erasure - a portal makes it easier for customers to see their own data, which is a genuine benefit, but requests to delete data still need a clear internal process behind it.
- Encryption in transit and at rest - table stakes for any internet-facing system holding customer data.
None of this is exotic, but it needs deciding before launch rather than discovered afterwards. If you're weighing up a portal against buying an existing self-service module from your CRM or finance vendor, it's worth checking what they already offer - sometimes that covers the need without a build at all. Where it doesn't, our pricing page gives a sense of what a well-scoped portal project looks like.
✦ Where this fits
More on this from us: our custom web application development service.