Client portal development. Built bespoke. Owned outright.
Client portal development is the design and build of a secure system where your clients see and act on their own records. Clientflow builds them for established UK teams replacing spreadsheets, email threads and rented portal software, priced from a blueprint, with the code and the accounts in your name.
What is client portal development?
A client portal is one view onto the system that already runs the work: your clients see and act on their own records, jobs, documents, approvals, invoices and requests, with your staff on the other side of the same data. Built bespoke, it is not a separate website bolted onto the business.
| Aspect | Is | Is not |
|---|---|---|
| Shape | One view onto the system that runs the work | A shared drive with permissions |
| Access | Authenticated, role-aware, audited | A help centre with a login |
| Fit | Built around your process | A CRM with a customer-facing tab |
| Control | Yours to change | A branded skin over a spreadsheet |
A client portal is rarely a client-facing problem. It is an internal operations problem with a login on the front of it, so the question that decides the build is not “what should clients see” but “which part of the work is being done twice”.
What a client sees
Version one is one workflow and nothing else. This is what it looks like from the client’s side, and from yours.
Approvals in the portal, not in an email thread
Every document a client has to sign off sits against the job it belongs to, with its version, who uploaded it and when. Approval is one action, recorded with a name and a time, and the next step starts the moment it happens. Nobody forwards a PDF and hopes.
The view your own team works from
A portal only removes work if your staff use it too. The internal view is part of version one: everything waiting on your team in one queue, everything waiting on a client in another, on the same records the client sees. One system, two sides, nothing re-keyed.
Notifications that fire when something changes
A client hears from the portal when something needs them, and only then: a document waiting for approval, a stage completed, an invoice raised. Nothing is sent on a schedule, so every message is worth opening, and every one links to the record it is about.
A record of who did what, and when
Every action in the portal is written to an audit trail the client can read: uploads, approvals, payments, stage changes, each with the person and the time. It replaces the email search at the end of a job, and it is the history that comes across intact if the portal is ever replaced.
Wired into the systems you already run
What the portal talks to
Each system keeps its own records. The portal reads and writes them directly, so nothing is entered twice.
- Accounting and ERPConnectedIts own API; Sage 50 through a sync agent.
- CRMConnectedYour records and fields, read and write.
- IdentitySingle sign-onYour directory for staff; one sign-in per client.
- Company dataCachedCompanies House, fetched at onboarding.
A portal is only worth logging into if it shows the same facts as the system that already holds the record. Clientflow builds portals that read and write that system directly, through its own API, rather than through a chain of automation steps nobody owns. Which systems, and in which direction, is settled in the blueprint, the written scope every build starts with, because that is what moves the price.
What we build first, and what we leave out
In version one
- Authentication with role-based access and a client-organisation boundary.
- One core object with a status timeline: the job, the case, the order, whatever your business counts.
- Document exchange with versioning and an audit trail.
- Notifications that fire when something changes, not on a schedule.
- The internal-side view your own team works from.
- One integration with the system that already holds the record.
Deliberately in the second phase
- A second client-facing workflow, once the first one is stable in real use.
- Reporting exports for the board pack, once you know which numbers get asked for.
- Automated invoice generation, after the billing data has proved itself accurate.
- Payment capture, which adds a reconciliation path your finance team does not currently have.
- In-portal messaging, which competes with email until the portal is the habit.
- A second integration, once the first has run through a full month-end.
Version one is one workflow done properly, in production, used by your clients and your staff. It is not a demo, not a prototype and not the finished platform. Scoping it narrow is what keeps the price fixed and the date real, and everything in the second phase is cheaper to build once people have used the first.
How much does client portal development cost in the UK?
Clientflow builds bespoke client portals from £10,000. A portal for status, documents and approvals usually sits in the first band, up to £25,000, and most of what established teams ask us to scope fits below £50,000. A version one then costs about £800 a year to run, with nothing per seat.
- Builds from
- £10,000
- A portal, first band
- £10k to £25k
- To run, about
- £800a year
- Per seat
- Nothing
Five things move the price: user roles, integrations, data, complexity and compliance. A sixth, migration, applies if an old portal’s history has to come across. The bands are on the pricing page, what moves a build between them is in the cost guide, and the running costs, itemised at list prices, are in the running-costs guide. The blueprint turns a band into a fixed price in writing, which only moves if you change the scope.
How long does it take to build a client portal?
A version one of a bespoke client portal takes weeks rather than quarters: one to two weeks of blueprint, then three to eight of build. Dates neither of us controls, such as a supplier granting access to its API, are named as such rather than promised. Larger builds run longer: the three systems in our work were scoped at four, six and sixteen weeks to a version one.
- 1FreeBlueprint callDay one
Twenty minutes with the people who would scope the build, to work out what version one should contain, or whether to build at all.
- 2ScopedBlueprintWeeks 1 to 2
The workflow, the users, the integrations and the risks written down, with a clickable prototype, so the build is agreed before it starts.
- 3BuiltBuildWeeks 3 to 8
Designed and built, AI-assisted for speed with a senior engineer reading every change, wired into the systems you already run.
- 4OwnedLaunch and handoverHandover
Code, environments and documentation transferred to you, your team trained, and a warranty after launch.
Who owns the code, the data and the accounts?
You do, from the first week.
Yours from the first week
Arranged before the build starts, not negotiated at the end.
- The codeA repository in your name from the first week.Yours
- The accountsHosting and database opened in your name, in the region you choose.Yours
- The intellectual propertyAssigned to you under the agreement.Assigned
- The stackNext.js, TypeScript, Supabase, PostgreSQL and Vercel.Standard
- At handoverYou hold every account outright, including the ability to remove us.Yours
That is worth checking with every supplier you speak to, because UK copyright law does not hand it over by default. The author of a work is its first owner1, the rule that gives an employer its staff’s work does not cover a contractor, and an assignment is only effective in writing, signed by the assignor2. Paying the invoice is not what transfers the copyright.
Replacing a client portal you already have
Portals get replaced for two reasons: the product stopped fitting, or nobody can maintain the earlier build. Either way the work is the same shape. Extract the data and the document history, run the new system alongside the old one on real data, move client logins across in groups, and bring the audit trail with them.
Should you build a client portal or buy one?
Buy off-the-shelf portal software when the workflow behind the login is genuinely standard and you are willing to change your process to fit the tool. Build bespoke when the portal has to follow the way your business already operates, when per-seat pricing across your clients compounds, or when the data and the code need to be yours. Most companies need one, not both.
| Factor | Buy | Build |
|---|---|---|
| Time to go live | Days | Weeks |
| Up-front cost | Low | Fixed, from a blueprint |
| Ongoing cost | Per seat, forever | Usage, about £800 a year |
| Fit to your process | You adapt | It adapts |
| Ownership | Licensed | Yours |
Run cost is the figure in the own-or-rent guide, for a version one at list prices. The same guide works the per-seat arithmetic through for a team of twenty.
When we will tell you not to build
Some calls end with us recommending a product and sending no invoice, and we would rather that than the alternative: a build that does not pay for itself is a bad reference and a worse relationship. That is why the blueprint call is free.
- You need document exchange and nothing else. Buy a document portal and keep the money.
- You need a help centre and a ticket queue. A support suite already does that better than a build would.
- The workflow behind the login is genuinely generic. If a product fits, the product wins, and we will point you at the setting.
- Or one of the three reasons that apply to any build: the process is still changing every month, nobody inside the business owns it, or the budget is under £10,000.
Questions people ask about client portals
Sources
Every citation above was read from the page cited, on the date shown.
- 1Copyright, Designs and Patents Act 1988, section 11, legislation.gov.uk. Seen 5 September 2026.
- 2Copyright, Designs and Patents Act 1988, section 90, legislation.gov.uk. Seen 5 September 2026.
Go deeper
The guides behind the numbers on this page, each with its sources and the date they were read.
