Client Portals for Small Businesses: SaaS or Custom, and What Each Costs

Quick answer

A client portal is a private area where customers see their own stuff — job status, documents, invoices, messages — instead of emailing you to ask. It pays for itself the moment “just checking where we’re up to” emails consume real hours: for most small firms that’s somewhere past 20–30 active clients. The build decision follows the usual ladder: your existing software’s built-in portal first (£0 — accounting and job-management tools often include one), dedicated portal SaaS second (£20–£100/month), and custom builds (£3,000–£15,000) only when the portal is the service experience or must do things no product does.

What a portal actually fixes

• The status-chasing loop. Every “any update?” email is a symptom: the client has no window into their own project. A portal converts interruptions into self-service — the same logic as parcel tracking, which killed “where’s my delivery?” calls.
• Document ping-pong. Contracts, proofs, statements and certificates scattered across email threads become one findable place — with a record of who saw what, when. For document-heavy trades (accountancy, legal, design approvals, building compliance), this alone justifies the tool.
• The professionalism gap. A branded portal reads as an established firm. For businesses moving upmarket it’s part of the same story as the identity and website: looking like the fees you charge.
• Payment friction. Portals that show invoices with a pay button collapse debtor days — the machinery covered in business process automation gets a front door clients actually visit.

The three routes, honestly priced

Work down only when the rung above genuinely fails — the discipline from custom vs off-the-shelf applies squarely here. The custom trigger that’s actually common: the portal must pull live data from two or three systems (job management, accounting, file storage) into one client view — that’s an integration project wearing a portal’s clothes, and it’s where our custom software work usually starts.

Features that matter (and the ones that don’t)

Worth insisting on: login simplicity (magic links beat passwords for occasional users), mobile-first views (clients check status from phones), branded appearance, notification controls (digest emails, not a ping per event), and payment/e-sign where relevant. Overrated in practice: real-time chat (an inbox nobody staffs is worse than email), elaborate dashboards for clients who visit monthly, and client-side file editing — view, approve, download and upload cover 95% of real use. Start embarrassingly small: a portal showing status, documents and invoices, used by every client, beats a feature-rich one nobody logs into.

The UK data responsibilities

A portal concentrates client personal data, which sharpens UK GDPR basics: access control (clients see only their own records — the classic portal bug is an ID in the URL exposing everyone else’s), retention rules (old client data needs a deletion policy, not immortality), breach readiness (know what’s in there and who to tell), and a processor agreement with whatever SaaS or host holds the data. None of this is onerous — but it must be designed in, not bolted on, which is a real argument for either mature SaaS (they’ve done it) or a builder who treats it as a requirement rather than an afterthought. If your current “portal” is a shared spreadsheet emailed monthly, the whole ladder — and when to climb it — is mapped in outgrowing spreadsheets.

Where the money goes in a custom build

The £3,000–£15,000 range is unhelpfully wide until you see what sits inside it. A realistic breakdown for a first-version portal serving a professional services firm:

Two lines cause most budget overruns. The admin side is the one clients forget to specify and then discover they cannot operate without. And “live data from other systems” is the phrase that turns a £4,000 portal into a £12,000 one, because each integration brings its own authentication, rate limits and failure handling. Scope it deliberately: version one can be updated by staff manually and still remove 80% of the chasing emails. Writing that boundary down before you request quotes is the highest-leverage hour in the whole project, and the structure for it is in our guide to briefing a software project.

The adoption problem nobody budgets for

The most common failure is not a technical one: the portal works, and clients keep emailing anyway. Portals get abandoned when logging in costs more effort than typing a question. What reliably fixes it:

• Stop answering in the old channel. Reply to “any update?” with a one-line answer and a direct deep link to the exact page. Three of those and the habit forms.
• Deep links everywhere. Every notification email should land on the specific document or job, already authenticated where security allows — never on a generic login page that then loses the destination.
• Magic links over passwords. Clients who visit monthly will never remember a password, and a forgotten-password loop is where adoption dies.
• Onboard at the start of the relationship. Introducing the portal at kick-off, as “this is how we work”, gets near-universal use. Introducing it to existing clients halfway through a job gets polite indifference.
• Give it one thing they genuinely want. Usually documents-on-demand or an invoice history. A portal that only shows a progress bar is a novelty; one that holds the certificates they need at 8pm on a Sunday is infrastructure.

Questions to ask a portal SaaS vendor before signing

1. “How does pricing change at 50, 200 and 500 clients?” Per-client pricing is the trap. Model the cost at three times your current size before you migrate anything.
2. “Can I export everything, including files and message history?” Ask for a sample export during the trial. “You can download files individually” is a no.
3. “Where is the data hosted, and will you sign a data processing agreement?” Non-negotiable if you hold client personal or financial data — the surrounding obligations are unpacked in what GDPR-compliant software actually requires.
4. “How much branding control do I get?” Specifically: custom domain (portal.yourfirm.co.uk), your logo, your colours, and emails sent from your address. A portal that visibly belongs to a third party undercuts the professionalism it was bought to project.
5. “What is the client-side experience on a five-year-old Android phone?” Test it on real hardware. A portal your clients cannot use on the device they actually own is a portal nobody uses.

When a portal is the wrong answer

Three situations where the honest recommendation is to spend the money elsewhere. If your client base is under about fifteen and each relationship is high-touch, a shared cloud folder plus a disciplined weekly update email delivers the same outcome at zero cost and zero training. If the chasing emails are caused by genuinely slow delivery, a portal simply makes the delay visible in higher resolution — fix the operation first. And if your public website is where prospects lose confidence, the portal improves the experience only for people who have already bought; the money is better spent on the front door, which is why portal projects so often begin as a website design project with a secure client area added later.

Where a build genuinely is warranted, resist the urge to specify the finished vision. Ship the smallest version that removes the single most expensive interruption, watch what clients actually click for a quarter, then extend — the scoping discipline set out in scoping a first version that proves something. Portals built to a two-year wish list routinely launch with a dozen features and a login screen nobody has a reason to pass.

Sources & Further Reading

• UK GDPR Guidance — Information Commissioner's Office
• Xero UK — Xero
• Small Business Cyber Security — NCSC