A client portal looks like the cheapest thing on a software menu. A login, a list, a few documents, a status. People expect a number with one comma in it and are surprised when it has more.

The surprise comes from measuring the wrong thing. Screens are not what a portal costs. Sources are.

One system, three systems, five systems

A portal shows people facts that live somewhere else. Your accounting package knows what they owe. Your operations system knows where the order is. A drive somewhere holds the documents. The portal's job is to put those in one place, behind one login, and be right.

  • One source. Everything the customer sees already lives in a single system with a usable API. This is the cheap case, and it is genuinely quick.
  • Three sources. Now you need a rule for what to show when two of them disagree, and a rule for what to show when one of them is down. That is not a screen, that is a decision about your business, and it usually needs someone senior to make it.
  • Five sources, one of which is a person. Somebody exports a file weekly. The portal is now the place where that fact becomes visibly stale, in front of the customer.

We price a first version at $14,000 for eight weeks, and the range inside that is almost entirely this: how many systems, how well they answer, and whether anyone can decide what wins when they disagree.

The three questions that move the number

How does a customer get in, and get back in? Invitation, reset, expiry, and the case where the person who had the login has left the company and their replacement needs access to the same account. That last one is dull, unavoidable, and the first thing that goes wrong when it is skipped.

Who is allowed to see what? One company, several people, different rights. In the largest system we run, access resolves across brand, branch and city at once. Getting that wrong is the failure that never announces itself, which is the main reason the browser side of that system is covered by automated checks at all.

What can they do, not just see? A portal that only displays is half a portal. One action — approve, upload, request, pay — is what turns it from a report into a thing that removes work from your team.

What we would leave out of version one

  • Chat. Mature products exist, integrate well, and cost a fraction of building it.
  • A native mobile app. A portal that works properly in a phone browser covers this. Revisit it when you know people are using it daily.
  • Rebuilding the systems behind it. A portal is a window. If the data behind it is wrong, the portal will show it faithfully — which is uncomfortable, and occasionally the most valuable thing it does.

How to know it paid for itself

Before you build, count. How many emails a week ask where an order is, what is owed, or for a document to be re-sent? Multiply by the minutes it takes a person to answer. That number is your business case, and it is usually more convincing than anything a studio can tell you.

If it comes out small, do not build a portal. If it comes out large, you now also know which three screens to build first — the ones that answer those three emails.