A client portal for a professional services firm, scoped honestly

A law firm, an accountancy practice and an architecture studio walk into the same meeting and ask for the same thing: a place where clients can see their own stuff instead of emailing to ask for it. The brief is always called a client portal, and it is always bigger in the first document than it needs to be.

The useful version starts from a different question. Not what could a client see, but which four emails does this firm answer most often. Build the answer to those four and the portal earns its cost in the first month. Build the module list and you get a login page nobody uses, which is the normal outcome.

The four questions clients actually log in for

Across the professional services work we have scoped, the inbound questions cluster hard. In rough order of frequency: where is my matter or project right now, can I have a copy of that document, what do I owe and what have I paid, and who do I speak to about this. That is the portal. Everything else is a later phase pretending to be a requirement.

Notice what is not on that list. Clients rarely want to collaborate inside your system, they do not want a chat feature that competes with email, and they will not maintain a profile. A portal that asks the client to do work has misread the relationship: they are paying precisely so that they do not have to.

The failure that ends these projects

A client portal is a system whose entire job is to show person A their records and not person B's. That makes it a pure access control problem, and access control is the single most commonly broken thing in web applications.

OWASP's Top Ten ranks Broken Access Control first, moving up from the fifth position in the previous edition. It maps 34 separate weakness types and recorded 318,487 occurrences in the contributed dataset, the most of any category. The detail that should worry anyone commissioning a portal is the coverage figure: 94 percent of applications were tested for some form of broken access control, and the category still came out on top.

The specific failure is mundane. OWASP lists "permitting viewing or editing someone else's account, by providing its unique identifier" and describes an attacker who "simply modifies the browser's 'acct' parameter to send whatever account number they want". In a client portal that is one client reading another client's file, which for a law or accountancy practice is not a bug report, it is a regulatory and professional conduct event.

Two of OWASP's own recommendations are worth writing into the brief verbatim: "except for public resources, deny by default", and model access controls so they "enforce record ownership" rather than trusting that a user will only ever request their own identifier. If a vendor cannot explain how their design does both, that is the end of the evaluation, not a point to negotiate.

What belongs in phase one, and what does not

The first four are mostly read paths over data the firm already maintains. That is what makes them cheap. The moment the portal becomes a place where data is created, you have a second system of record and the reconciliation work that implies. We wrote about that trap in general terms in migrating from spreadsheets without losing the history.

Where the real cost sits

Not in the portal. In the connection between the portal and wherever the truth currently lives, which in these firms is a practice management system, a document store and an accounting package, usually three different vendors. The portal is a thin read layer over those. The integration is the project.

Price it that way from the start. The honest ranges and what moves them are in what an integration between two systems really costs, and the invoice half specifically tends to be the fiddliest because accounting systems model credit notes and part payments in ways a status badge does not survive. That is covered in automating invoice generation and the three places it breaks.

On login, resist the urge to build your own. A small firm with a handful of staff and a few hundred clients does not need an identity platform, but it does need password reset, lockout and session expiry to be someone else's problem. Where that line sits is in single sign-on for small companies and whether it is worth it yet.

The invoice question nobody scopes

Showing what a client owes changes the collections conversation, and firms underestimate this. Most late payment in professional services is not refusal, it is an invoice that reached the wrong inbox and a client who never saw a statement. A portal where the outstanding balance is simply visible removes a whole class of excuse on both sides.

It does not remove the awkward part, and the prevention work still has to happen in the engagement letter rather than in software. Khaled Badr's piece on dealing with a client who does not pay, prevention first is the commercial counterpart to this build, and it is the better place to start if late payment is the actual problem you are trying to solve.

An honest limit

Most firms under about fifteen people should not build this. If your practice management vendor offers a client portal module, switch it on, accept that it is ugly, and spend the budget on the document filing discipline that makes any portal useful. A portal over badly filed documents just exposes the filing.

The case for building is narrow and specific: you have two or three systems no single vendor portal can span, you have a client experience that is genuinely part of your positioning, or you have a confidentiality requirement that a shared multi-tenant product cannot satisfy. The decision order for that is in custom software versus off the shelf, decided in the right order, and if you get to a build, scope it properly before anyone writes a line of code.

One last thing to insist on regardless of build or buy. Ask for the access control test. Not a penetration test of the whole product, just a demonstration that a logged-in client who changes an identifier in the URL gets a refusal rather than a record. The reference for what is being tested is OWASP's Broken Access Control category. It takes ten minutes, it is the only test that matters for this class of system, and almost nobody asks for it.