How much does a customer portal cost to build?

Clients email asking where their invoice is. Then for a document you sent in March. Then for an update on where things stand. Someone on your team spends an hour a day finding things that already exist and sending them again.

A portal is worth pricing against that hour, not against a list of features. Which also means the honest question is not what it costs to build, it is whether your clients will use it. A portal nobody logs into is the most expensive thing in this article, and it is a common outcome.

What a portal actually replaces

Not a feature you are adding. A process you are removing, and it helps to be specific about which one.

• Re-sending documents that were already sent, which is the single most common request and the easiest to eliminate.
• Answering where are we up to, which is usually a request for a status you already know and have not published anywhere the client can reach.
• Collecting things from clients. Forms, files, approvals, signatures. Chasing this is frequently a bigger cost than answering questions.
• Invoice and payment queries, including the ones where the answer is that it was paid three weeks ago.
• The scattered history, where everything about a client exists across four inboxes and nobody can find the version that matters.

Write down which of those actually costs you time. If it is only the first, your project is far smaller than you think, and possibly not a portal at all.

Customer portal cost: the short answer

What actually drives the cost

Four things, and only one of them is the part people imagine when they picture a portal.

1. Sign-in and permissions. Sounds trivial and is not. Who can see what, what happens when a client has three staff with different access, how someone is invited and removed, what a client organisation means when it has subsidiaries. Getting this wrong shows one client another client's documents, which is the only failure here that is genuinely serious. Expect a real share of the budget, and be suspicious of a quote where it is a line item worth a day.
2. How many systems it connects to. The single biggest variable. A portal that stores its own data is straightforward. One that reads live from your accounting system, your project tool and your document store is four integrations, four sets of credentials, four things that change without warning, and four ways to be wrong. Each connection roughly adds what you would expect and then some.
3. Documents. Storage is cheap and the rest is not: versioning, permissions per file, previewing without downloading, expiry, and knowing who looked at what. If any of that matters, say so early because it changes the shape of the build.
4. Payments. Adds compliance considerations, refund and dispute handling, and reconciliation with whatever your finance team already uses. Worth doing and never a small addition.

Build, or buy something off the shelf

Worth taking seriously before commissioning anything, because for simple cases the answer is genuinely to buy.

Several categories of product already do most of this. Practice management tools for accountants and law firms usually include a client portal. Project tools have client-facing views. Accounting packages have customer portals for invoices and payments. Document platforms handle sharing and permissions properly. If your need is mostly documents, mostly status, or mostly invoices, one of these will cost a fraction of a build and be available on Monday.

Building becomes right when the portal has to reflect your specific process rather than a generic one, when it must pull from several systems that no product connects, when the experience is part of what clients are buying, or when you have enough clients that per-seat pricing on a product has become the more expensive option. Custom software vs off-the-shelf has a scoring framework for exactly this, and it recommends buying more often than building.

Adoption is the part that decides everything

Here is the failure we see most, and it has nothing to do with the software. The portal is built, it works, it is announced, and six months later a third of clients use it while the rest still email. Now you are running both, and you have added cost rather than removed it.

Nobody wants another login. Your portal is competing with an inbox your client already has open, which is a genuinely good product with no learning curve. Plan for that rather than hoping.

• Make it the only route for something they need. If invoices are only available in the portal, people will sign in. If it is a nicer copy of what arrives by email, they will not.
• Remove the login where you can. Secure links straight to a specific document, valid for a period, remove the largest single obstacle for occasional users.
• Send an email that links into it, rather than expecting anyone to remember to visit. The email is the habit; the portal is where it lands.
• Onboard the ten clients who generate most of the questions, personally, in the first fortnight. If they adopt it, most of your saving arrives.
• Accept that some never will, and decide in advance what you do about it. Usually you keep answering their emails, and that is fine as long as it was a decision rather than a disappointment.
• Measure sign-ins in month three, honestly, and be willing to conclude it was not worth it. That is a cheaper conclusion than pretending.

If most of the pain is really chasing clients for things rather than answering them, workflow automation may deliver more for less, and if the underlying problem is that nobody can get a straight answer out of your own data, that is reporting rather than a portal.

What it costs after launch

A portal is not a project that finishes, and this is the line people leave out of the business case. It holds client data behind a login, which makes it the piece of your estate that can least afford to be neglected.

• Security patching, indefinitely. Anything with client documents behind a sign-in is worth attacking, and the routine work of keeping dependencies current is not optional the way it might be on a brochure site.
• The connections will break. Every system you integrate with will change its interface eventually, usually without warning you personally. Someone has to notice and fix it, and until they do the portal is showing stale data, which is worse than showing none.
• Client administration. People join and leave your clients' organisations constantly. Somebody has to add and remove them, and if that somebody is you rather than the client, it is a job you have created.
• Support you did not have before. Clients will forget passwords, use old links and ask why a document is not there. Modest per client, real in aggregate, and it lands on whoever answers the phone.
• The requests that follow. Once clients use it, they will ask for the next thing. That is success, and it is also a budget.

Budget roughly 15 to 25 per cent of the build a year to keep it healthy, before any new features. A portal nobody maintains becomes a liability faster than most software, because the thing going stale is your clients' own information.

A cheaper first step

Before committing to any of the ranges above, try this for a month. Take the single most common request, and remove it without building anything: a status page, a shared folder with a strict naming convention, an automated monthly statement, whatever fits. It costs almost nothing.

If the volume of emails drops noticeably, you have learned that the problem is real and a portal will pay back, and you now know which part to build first. If it does not drop, you have saved yourself a large amount of money and discovered that the emails were not really about documents at all. Either outcome is worth a month.

Not for you if

The most useful question before commissioning one: what would clients be unable to do any other way? If there is a clear answer, they will use it. If the honest answer is nothing, build the thing that answers it first, and the portal second.