Client Portal Development: What to Build and What It Costs

A client portal earns its keep by removing emails. Every feature should be judged against that: does it stop someone asking a question, sending a document, or chasing a status? If not, it is decoration.

What a client portal is for

Accountants, solicitors, letting agents, recruiters, agencies, training providers, consultancies: any business that has an ongoing relationship with clients and a stream of documents, approvals and status questions running through it. The portal gives each client a login and shows them their own things - and only their own things - so they stop asking you for them.

We build portals as custom web applications, usually connected to the internal system that already holds the data, so the portal is a window onto the truth rather than a second copy of it.

The features that reduce email

Documents, in both directions

Clients see what you have sent them and upload what you need from them. Version history, so "which one is the latest" stops being a question. Requests with deadlines, so "have you sent the thing" stops being an email.

Status, visible

Where their matter, job, application or project is right now, in plain words. This is the single feature that removes the most email, and it is the one most often built badly - as a technical status code rather than a sentence a client understands.

Approvals and signatures

Quotes, proofs, drafts, contracts: approve or comment in the portal, with a record of who did what and when. Integrating an e-signature provider is cheaper than building signing yourself.

Invoices and payments

See invoices, pay them, download receipts. Sync with your accounting system so nobody re-keys anything. This alone often justifies the portal for professional services firms.

Messages, tied to the thing

A message thread attached to a matter or job, not a general inbox. The value is that the conversation lives next to the documents it is about.

The features that look impressive and rarely pay

• Dashboards with charts clients did not ask for.
• Real-time chat, which creates an expectation of real-time replies.
• A client-facing mobile app in phase one. Make the portal work well on a phone first; a native app is a separate decision, covered in our app cost guide.
• White-labelling for clients' clients. Real need for a few businesses, scope explosion for most.

What it costs in the UK

A portal showing documents, status and invoices, connected to one internal system, with a single client role: £8,000 to £18,000, 6 to 10 weeks. Add approvals, uploads with requests, messaging and payments, plus staff-side administration: £18,000 to £40,000, 10 to 14 weeks. Multi-entity portals (clients who are themselves companies with their own users and permissions) and partner APIs push beyond that. The general reasoning is in our web application cost guide.

Security is not optional

A portal holds other people's confidential data behind a login. Non-negotiables: UK hosting, encryption in transit and at rest, per-client data isolation tested rather than assumed, two-factor authentication available, audit logging of who accessed what, and a data retention policy you can state in your privacy notice. Ask any agency how they test that client A cannot see client B's documents. If the answer is vague, keep looking.

Writing the brief

Three lists: who logs in (client, staff, maybe partner), what each of them needs to do (five things each, no more), and what internal systems the portal must read from or write to. Add the top ten questions clients email you today; the portal should answer at least seven of them without human involvement. That brief is enough for a fixed quote. Our guide to briefing a software agency covers the rest.

Adoption: the part that decides whether it worked

A portal that clients do not use is an expense. Adoption is designed, not hoped for. Three things move it more than anything else.

Make the portal the only place some things happen. If clients can still email a document, they will. Invoices, document requests and approvals should live in the portal and only in the portal, with email used to notify, not to transact.

Onboard each client personally the first time. A two-minute walkthrough on a call converts far better than an automated welcome email. Track who has logged in and chase those who have not within a week.

Make login painless. Magic links or single sign-on beat passwords. Two-factor should be available and, for sensitive data, required, but it should be the app-based kind that takes three seconds.

Integration is where portals succeed or fail

A portal that is a second copy of your data becomes stale within a month, because staff update the internal system and forget the portal. The portal must read from the system of record: practice management, case management, your CRM, your accounting package. If that system has no API, the portal project becomes partly a project to give it one, and the quote should say so. We build most portals as a front end to an existing CRM or operational system, or build both together when the internal system is also being replaced.

A phased plan that works

Phase one: documents, status and invoices, read-only from your side, for a group of friendly clients. Six to eight weeks. Phase two: uploads, requests, approvals and messaging, rolled out to everyone. Phase three, if needed: payments, a mobile app, partner access. Each phase is used before the next is built, so phase two is shaped by what phase one taught you rather than by the original guess.

Common mistakes

• Building the client side first and the staff side never. Staff need to manage requests, respond to messages and see who has not uploaded. Without that, the portal creates work rather than removing it.
• Copying data instead of connecting to it. Covered above; it is the most common reason portals go stale.
• Notifying too much. An email for every document view trains clients to ignore the emails that matter. Notify on things that need action.
• No offboarding. When a client leaves, what happens to their data and their login? Decide before launch; it is a data protection question as much as a product one.
• Launching to everyone at once. Ten friendly clients first, for a month, then the rest.

Each of these is cheap to get right at scoping and expensive to retrofit, which is why they are in the brief template above.

One last point on scope: a portal is a product your clients judge you by. The cost of getting the first version small and right is far lower than the cost of a large first version that clients try once and abandon, because a second launch is much harder than a first.

If you have that list, or want help writing it, send it over.