What Does a Customer Portal Cost to Build?

In New Zealand, published ranges put a simple portal or internal tool at $15,000–$40,000, a mid-complexity platform at $40,000–$120,000, and enterprise builds well above that. The number is driven far more by roles and permissions than by screens — the cost scales with how many distinct answers there are to "who is allowed to see or change this record?", not with how many pages you draw.

That's the part most portal quotes get wrong, and it's why two quotes for "a customer portal" can differ by a factor of five.

Want to know which band you're in? Tell me who logs in and what each type of user is allowed to see, and I'll tell you honestly — including if an off-the-shelf tool would serve you better. Get in touch.

What a customer portal actually is

A portal is a logged-in area where the same underlying records look different depending on who's looking at them. A customer sees their own orders, invoices and documents; your staff see all customers; a manager sees staff activity as well.

That definition matters because it separates a portal from a login. A login proves who someone is. A portal decides what they're allowed to do — and the second problem is much harder than the first. If you only need the door rather than the building, what it costs to add a customer login is the cheaper conversation.

What drives the cost

1. Roles and permissions — the dominant factor

One role is a feature. Two roles is a feature with a condition. Four roles with overlapping rules — where a manager can see a staff member's records but not another manager's, and a customer can see their own invoices but not their neighbour's — is an authorisation model, and it has to be designed before anything gets built.

The rule that keeps it safe is that permissions are enforced on the server, so the UI only ever hides what the API already refuses. On the hospital system I built, role-based access was designed first for exactly that reason: reception, doctors and administrators all need the same patient record, each needing it to show something different, and getting that wrong isn't a UI bug — it's a records breach. Removing the client-side check by hand gets you a refusal, not a patient record. A hidden button is a convenience, never a security boundary.

2. Integrations

A portal that shows data is cheap. A portal that shows data from your accounting system, your CRM and your inventory is priced by the quality of those systems' APIs — their rate limits, their downtime, and what your portal does when a sync fails halfway through. This is the line item most likely to be underestimated by whoever quotes it.

3. Data volume and shape

Ten thousand records and five hundred thousand are different engineering problems. Beyond a certain size, screens have to be paginated, searches have to be indexed on the fields people actually search by, and reports have to be computed on the server rather than assembled in the browser.

4. Security requirements

If the portal holds health, financial or personal data, the requirements stop being technical preferences and start being obligations — encryption at rest, audit logging of who accessed what, and a retention policy. NZ providers price penetration testing at $3,000–$8,000 as a separate line (Web Maniacs), and on a portal holding sensitive records that's money well spent.

Published ranges

New Zealand (NZD)

The overlap between those two sources is real and worth understanding: the low end assumes a tightly scoped MVP with one or two roles, and the high end assumes the permission model described above. Sources: Web Maniacs and Kweb.

Cyprus (EUR)

Cyprus providers publish less detail on application work than on websites, but the relevant bands are €6,000+ for a custom or advanced platform (Bandziuk) and €12,000–€35,000 for a premium or headless build (Uveler). Ongoing maintenance runs €100–€500/month.

The costs quotes usually leave out

That maintenance figure is the one people budget for least and regret most. A portal nobody maintains becomes a security liability within about a year, because it holds user accounts and the dependencies underneath it keep aging whether or not anyone is watching.

Build vs off-the-shelf

Before commissioning anything, check whether the portal you want already exists as a product. Client portals for accountants, law firms, agencies and trades are mature categories, and a subscription that works today usually beats a custom build you also have to maintain.

Build custom when your permission rules can't be expressed in the off-the-shelf tool, when the portal is genuinely part of your product rather than an admin convenience, or when integrating your existing systems is the whole point. Buy off-the-shelf when you mainly need to share documents and status with customers, which is most of the time.

When a shared folder and an email would do

Worth saying plainly, because it's the answer more often than the industry admits. If you have under about fifty customers, each needs to see only their own documents, and the documents change rarely, then a well-organised shared drive with per-client folders plus an email when something changes will do the job for effectively nothing.

The point at which that stops working is when you're spending real time on the manual version, when customers ask "where's my file?" often enough to be a support cost, or when you need an audit trail of who saw what and when. Until then, a $40,000 portal is solving a problem you don't have yet.

What I'd recommend

Write a permissions table before you talk to anyone: every type of user down one side, every type of record across the top, and in each cell whether that user can see it, edit it, or neither. It takes an hour.

That table is the actual specification of your portal. It's what a developer needs to quote accurately, it's what turns incomparable quotes into comparable ones, and filling it in frequently reveals that you need three roles rather than the six you assumed — which is the cheapest scope reduction available to you.

Frequently asked questions

How much does it cost to build a customer portal?

Published NZ ranges put a simple portal or internal tool at $15,000–$40,000, a mid-complexity platform at $40,000–$120,000, and enterprise builds at $120,000 and up. A second NZ provider quotes $10,000–$20,000 for a tightly scoped MVP. The variable that moves the number most is the number of distinct user roles and the rules governing what each can see.

What's the difference between a customer portal and a login?

A login proves who someone is; a portal decides what they're allowed to do. In a portal the same underlying records look different depending on who is looking — a customer sees their own invoices, staff see all customers, a manager sees staff activity too. That authorisation model is the expensive part, and it's why portals are priced as software rather than as pages.

Should I build a custom portal or buy one?

Buy off-the-shelf if you mainly need to share documents and status with customers — client portals are a mature product category and a subscription beats a build you also have to maintain. Build custom when your permission rules can't be expressed in the ready-made tool, when the portal is part of your product rather than an admin convenience, or when integrating your existing systems is the actual point of the project.

What are the ongoing costs of a customer portal?

In NZ, published figures are $200–$2,000/month for hosting and infrastructure, $1,500–$5,000/month for a mid-complexity support retainer, and an annual maintenance allowance of 15–20% of the original build cost. Budget the maintenance explicitly — a portal holds user accounts, and one nobody maintains becomes a security liability within about a year.

How do I keep portal permissions secure?

Enforce them on the server, so the interface only ever hides what the API already refuses. If someone removes a client-side check by hand they should get a refusal rather than the data. Ask any developer directly where permissions are enforced — if the answer is about hiding buttons or routes in the front end, that's not a security boundary, and on a portal holding customer data it's the difference between a UI bug and a breach.

Where to start

Fill in the permissions table. If it has two roles and one record type, you may not need a portal at all. If it has six roles and eight record types, you now have the document that will save you the most money in this entire project.

Send it to me and I'll tell you what band you're in and where the risk sits — free, and including the cases where I'd point you at an existing product instead. Get in touch, or see what I build.