Client portal development. Built bespoke. Owned outright.

What is client portal development?

Client portal development is the design and build of a secure, authenticated system where a company’s clients can see and act on their own records: jobs, documents, approvals, invoices, requests. Built bespoke, a client portal is not a separate website bolted onto the business. It is one view onto the operational system that already runs the work, with staff on the other side of the same data.

A client portal is rarely a client-facing problem. It is an internal operations problem with a login on the front of it. That is why the question that decides the build is not “what should clients see”, but “which part of the work is being done twice”.

Client portal and customer portal describe the same technology serving different relationships. Client portals usually carry fewer, higher-value relationships with named contacts, documents and approvals, which is the pattern in professional services, construction, finance and agencies. Customer portals usually carry higher volumes with lighter interactions. The build differs mainly in how permissions and organisations are modelled.

Should you build a client portal or buy one?

Buy off-the-shelf client 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 encode the way your business already operates, when external user numbers make per-seat pricing compound, or when the data and the code need to be yours. Most companies need one, not both.

Put plainly: a product is faster and cheaper to start, and you pay for it forever in licence fees and in the compromises your process makes to fit it. A build costs more up front and settles into usage and change, and it fits the way you already work because it was written to.

When you should buy off-the-shelf

1. You need document exchange and nothing else. A document portal already does this well.
2. You need standard support deflection with a knowledge base. A support suite will beat a build on both cost and time.
3. You have fewer than roughly 25 external users on a genuinely standard process. Per-seat pricing has not yet turned against you.
4. Your budget is under £10,000. Tighten what you already have rather than half-fund a build.

When a bespoke build earns its cost

1. The workflow behind the login is the thing that makes you different.
2. Per-external-seat cost crosses build cost inside your planning horizon. The own or rent guide works that arithmetic through for a team of twenty.
3. You need audit logging, full white-labelling or stated data residency, and they sit at the top of the vendor’s pricing ladder or are absent entirely.
4. The integration you need goes deeper than the vendor’s connector.
5. You need the data in a database you can query, export and hand to a successor.
6. You cannot accept the platform risk of a product that may reprice, rebrand or close.

What we build first, and what we leave out

A first release is one workflow done properly, in production, used by real clients and real staff. It is not a demo, not a prototype and not the finished platform. Scoping it narrow is the mechanism that keeps the price fixed and the date real.

In the first release

1. Authentication with role-based access and a client-organisation boundary.
2. One core object with a status timeline: the job, the case, the order, whatever your business counts.
3. Document exchange with versioning and an audit trail.
4. Notifications that fire on state change, not on a schedule.
5. The internal-side view your own team works from.
6. One integration with the system that already holds the record.

Deliberately in the second phase

1. A second client-facing workflow, once the first one is stable in real use.
2. Reporting exports for the board pack, once you know which numbers get asked for.
3. Automated invoice generation, after the billing data has proved itself accurate.
4. Payment capture, which adds a reconciliation path your finance team does not currently have.
5. In-portal messaging, which competes with email until the portal is the habit.
6. A second integration, once the first has run through a full month-end.

Everything in the second phase is cheaper to build once real people have used the first one. Nothing here is left out because it is difficult.

How much does client portal development cost in the UK?

Clientflow builds bespoke client portals from £10,000, and a portal for status, documents and approvals is the worked example in our first published band, £10,000 to £25,000. Most of what established teams ask us to scope fits between £10,000 and £50,000.

The three bands, and what moves a build between them, are in the cost guide. The blueprint turns a band into one figure in writing, and that figure only moves if you change the scope.

What moves the number

• User rolesHow many distinct roles there are, and whether client organisations administer their own users.
• IntegrationsHow many systems of record must stay in sync, and in which direction. Each one is real work, and each one is where a cheap quote hides its shortcuts.
• DataWhether the data model already exists, or has to be discovered first. Starting clean is cheap. Moving three years of records out of an old tool, with its inconsistencies, is a project inside the project.
• ComplexityBranching rules, calculations, states and exceptions. Approve or reject is simple. Approve unless the value is over a threshold and the requester is not a director, in which case route to finance, is not.
• ComplianceData residency, audit logging, accessibility conformance, and how long you are obliged to retain documents.
• MigrationWhether an existing portal has to be replaced with its history intact.

What it costs to run

A version one costs about £800 a year to run, with nothing per seat: hosting, the database and sign-in, transactional email, error monitoring and a domain. Every account is opened in your name from week one and you pay the provider directly, so nothing is routed through us or marked up. The itemised list, at list prices with the dates they were read, is in the cost guide.

How long does it take to build a client portal?

A first release of a bespoke client portal takes weeks rather than quarters. The blueprint takes one to two weeks, the build three to eight, and the dates neither of us controls, such as an app-store review, are named as such rather than promised. Larger builds run longer: the three systems on our work section were scoped at four, six and sixteen weeks to a version one.

What has to be true

1. Scope is fixed in writing before the build starts.
2. One named process owner inside your business, with the authority to decide.
3. Feedback in consolidated rounds, within a couple of working days.
4. If any of those slip, the date moves, and we say so the week it happens rather than the week before launch.

Who owns the code, the data and the accounts?

On a Clientflow build, the code lives in a repository in your name from the first week, the hosting and database accounts are opened in your name in the region you choose, and the intellectual property in everything made for you is assigned under the agreement. At handover every account moves into your name, including the ability to remove us.

What that phrase means in practice is worth checking with every supplier you speak to, including us, because UK copyright law does not hand it over by default.

What UK law says by default

The author of a work is the first owner of any copyright in it, subject to the following provisions.1

Copyright, Designs and Patents Act 1988, s.11(1)

An assignment of copyright is not effective unless it is in writing signed by or on behalf of the assignor.2

Copyright, Designs and Patents Act 1988, s.90(3)

The employer exception at section 11(2) covers a work “made by an employee in the course of his employment”1. It does not cover a contractor. So on a commissioned build the developer is the first owner unless something else has happened, and the something else the Act names is a signed writing. Paying the invoice is not what transfers the copyright.

What to ask any supplier, including us

1. Is there a written assignment of copyright, and at what point does it execute?
2. Where does the source repository live, and who administers it?
3. Whose name are the cloud, domain and third-party accounts in?
4. What documentation exists, and is it written during the build or at the end?
5. Could another developer take this over without you in the room?
6. What are the third-party licence terms, and is each one perpetual?

We answer those six the same way whether or not you are talking to us, and the stack is chosen so that the fifth answer is easy: Next.js, TypeScript, Supabase, PostgreSQL and Vercel. Widely used, widely taught, no in-house framework, nothing exotic to learn. The ownership section on the homepage shows the same thing as a working account ledger.

Integrating with the systems you already run

A portal is only worth logging into if it shows the same truth as the system that already holds the record. Clientflow builds portals that read and write into that system directly, through its own API, rather than through a chain of automation steps that nobody owns.

• Accounting and ERPSage differs materially by product line, and Sage 50 is on-premises, so it needs a sync agent rather than a cloud call. That difference is settled in the blueprint, not discovered mid-build.
• CRMRead and write against the object model you already use, so the portal never becomes a second source of truth.
• IdentitySingle sign-on for your staff against the directory you already run. Client-side sign-in is scoped to the client organisation, not to your internal directory.
• Company dataThe Companies House public data API is rate-limited, so company and director lookup is cached at onboarding rather than called on every page view.

Replacing a client portal you already have

Portals get replaced for two reasons: a product stopped fitting, or an earlier build is one nobody can maintain. Either way the work is the same shape. Extract the data and the document history, run the new system alongside the old one, move client logins across in stages, and bring the audit trail with them.

• ExtractionBefore you commit to anything, check one thing. Can you export every record and every document today, in a format another system can load, without opening a support ticket? If not, that is the finding.
• Parallel runningThe new system runs alongside the old one on real data, so the comparison is observed rather than argued.
• Staged cutoverClient logins move across in groups, not on a weekend. The rollback is always one group wide.
• Audit historyThe record of who did what, and when, comes across with the data. A migration that loses the audit trail creates a problem you did not have.

When we will tell you not to build

Some calls end with us recommending something other than a build, and we would rather that than the alternative. A build that does not pay for itself is a bad reference and a worse relationship.

1. You need document exchange and nothing else. Buy a document portal and keep the money.
2. You need standard support deflection with a knowledge base. A support suite already does this better than a build would.
3. The workflow behind the login is genuinely generic. If a product fits, the product wins, and we will point you at the setting.
4. Your process is not stable yet. Software fixes a process in place. Run it by hand for a quarter, then build the version that survived.
5. There is no one inside the business who owns the process. Without a decision-maker, a build stalls and you pay for the stall.
6. Your budget is under £10,000. It is not that the work cannot be done. It is that it cannot be done well at a fixed price.

Questions people ask about client portals