Skip to content

Custom Software

What a client portal actually costs to build

Three very different things get called 'a client portal'. Knowing which one you need is most of the budget.

All resources

· 4 min read

Most of the quotes we're asked to beat aren't wrong about the price. They're wrong about the scope. "A client portal" is not one thing, and the difference between the cheapest honest version and the most expensive honest version is about six times the budget — so the first job is working out which one you actually need.

Here's how we break it down.

The three portals people mean

When a business asks for a portal, they almost always mean one of three things.

A shared window. Clients sign in and see status: where their project or case or order is, what's outstanding, what's been delivered. Data flows one way — out of the systems you already run. There is no new source of truth, and that's what keeps it cheap. Expect four to seven weeks.

A working surface. Clients don't just look, they act: approve a deliverable, upload a document, sign something, leave a comment that reaches the right person. Now the portal writes back, which means permissions, audit trails, notifications, and a real answer to "what happens when two people act at once." Eight to fourteen weeks.

A system of record. The portal is where the work lives. Your team runs the engagement inside it, clients see their slice of it, and the spreadsheet it replaced gets deleted. This is a product build, not a website feature. Sixteen weeks and up, and it should be staged.

The expensive mistake is quoting the first and building the third. It happens because the requirement that turns a window into a system of record is usually discovered in week five, phrased as "and obviously the team needs to update it from their side."

What actually drives the number

Screens are cheap. These are what cost money:

  • Integrations. Every external system the portal reads from or writes to is its own small project — authentication, field mapping, error handling, and a plan for what the portal shows when that system is down. One integration is a line item. Four is half the budget.
  • Permissions. "Clients see their own data" sounds like one rule. In practice it's a matrix: owners, staff, external collaborators, archived accounts, someone who left the client's company last month. Model it early; retrofitting authorisation is one of the genuinely painful refactors.
  • Compliance. If the portal touches financial, health, or legal data, then audit logging, retention rules, encryption at rest, and access reviews stop being optional. This is not expensive because it's hard — it's expensive because it has to be right everywhere, not in one place.
  • Migration. Getting five years of existing records in, cleanly, with the mess reconciled, is routinely underestimated by an order of magnitude. Ask what the data looks like before quoting.

And one thing that costs less than people expect: design. A portal is a tool for people who use it every week. It needs to be clear and fast, not decorative.

Buy before you build

We turn down portal projects fairly often, because an off-the-shelf tool already does it. If your requirements are close to a standard shape — support ticketing, straightforward file sharing, generic project status — a subscription will beat a build on both cost and time, and you'll get updates you didn't have to pay for.

Custom is worth it when one of these is true:

  1. The workflow is genuinely yours, and bending it to fit a product's assumptions loses you the thing you're good at.
  2. The portal has to sit on top of systems that no off-the-shelf tool integrates with.
  3. Client experience is part of what you sell, and a tool with someone else's branding and someone else's roadmap undercuts it.
  4. Per-seat pricing on a growing client base has crossed the point where a build pays back inside two years.

If none of those are true, the honest answer is a subscription and a good onboarding.

How to get a quote that holds

Bring three things to the conversation and any competent studio can quote accurately:

  • A list of the systems it must talk to, with links to their API docs if you have them.
  • The roles, and one sentence per role on what that role can see and do.
  • One real example of the work — an actual project, matter, or account, with its real messiness intact. Not a clean sample.

That's usually enough to size the build within about 15%. Without it, every number you're quoted is a guess, including ours — and the cheap guesses are the ones that turn into change requests later.

Innovate. Transform. Thrive.

Tell us about your project. We’ll scope it, quote it, and set you up in your private Benix portal — with WhatsApp on speed-dial the whole way.

Free consultation · No obligation · We usually reply within a few hours