A login area where every client sees only their own file

What this actually solves

You come to a portal after the same small task has repeated itself often enough that you can no longer ignore it. An accounting practice emailing statements to forty clients. A law firm answering the same question — where has my matter got to — by writing a short email several times a day. A clinic sending results out one message at a time. A studio sending the same three files to a client who has lost them again.

The obvious cost is time, and it is significant, but it is not the worst part. The worst part is that this way of working has no memory. Nobody can say with certainty which version a client actually received, or when, or whether they opened it. Documents live in inboxes and messaging apps that were never designed to hold them, are backed up inconsistently, and are frequently readable by whoever happens to be holding the phone. For anything financial, medical or legal, that is an exposure that grows quietly with the client list.

A portal replaces the repetition with a place. Each client signs in and sees their own documents, their own invoices, the current status of their own work — and nothing belonging to anyone else. It is smaller than a full software product and considerably more than a website, and its entire value rests on one property being correct: that the separation between accounts genuinely holds. Everything else in this build is straightforward. That one thing is where the care goes.

What we do, and in what order

1. Define the roles and what each one can reach. Usually at least an administrator who can see everything and a client who can see only their own records, but real organisations tend to have more — a staff member limited to their assigned accounts, a read-only reviewer, a client with several people from the same company. Every combination is written down before any code exists, because access rules retrofitted later are the ones that leak. Two to three days.
2. Build authentication and the data model with isolation at the bottom. Sign-in, password reset, and a schema where every record carries its owner. The rules restricting access are enforced in the database and on the server, so that even a request that never touches your interface returns nothing it should not. This is deliberately built before any screen exists, so no feature is ever written against an unprotected data layer. One to two weeks.
3. Build the client-facing area, then the admin side. The client sees their documents, invoices and status. Your team gets the side that matters more day to day — adding clients, uploading, updating status, deactivating accounts — because a portal your staff cannot administer without calling us has simply moved the bottleneck. Two to three weeks.
4. Secure file handling. Uploads with type and size limits, storage that is not publicly reachable, and download links that are generated per request and expire, so a link forwarded or found later does not become a permanent open door to a document. File handling and permissions together are consistently the two areas that consume the most time on this build. Four to seven days.
5. Notifications. When something is posted for a client, they are told, with enough context to know whether it needs them. Without this the portal competes with email and loses, because people do not log in speculatively to check whether anything happened. Two to four days.
6. Adversarial testing with real accounts, then handover. Several genuine accounts created, then a deliberate attempt to cross between them — altering identifiers in addresses, calling data endpoints directly, opening a file link while signed out, attempting to escalate an account's own role. Findings are written up with what was tried and what happened. Then staff training, recorded on your live system. Four to six days.

What moves the price

The range is $2,000–$10,000 over 4–8 weeks, and it is set by three things that tend to travel together.

How many roles there are, and how they overlap. Two roles is a clean build. Five roles, especially where one client organisation has multiple users with different levels of access, multiplies both the rules and the tests required to trust them.

Whether files are involved, and in which direction. Download-only is simpler. Two-way upload brings validation, scanning, storage costs and notification, and it is where a meaningful slice of the timeline goes.

Whether data comes from systems you already run. A portal that your team populates by hand is quicker to build and slower to live with. Connecting it to your accounting package or CRM removes the double entry, and each connection is scoped and priced on what that system actually allows.

What usually goes wrong

Separation is implemented in the browser. The application requests all the records and the interface displays only the ones belonging to the signed-in user. On screen it looks perfect. In reality every client's data has already been sent to every client's device, and anyone who opens the browser's network tools — or simply calls the same address directly — has all of it. This is the defining failure of this service, it is common in otherwise competent work, and it is why the access rules here are enforced in the database and on the server before a single screen is built.

File links that work for anyone who has them. Documents get stored somewhere publicly reachable with an unguessable address, and everyone treats unguessable as private. Then a link is forwarded, or ends up in a browser history on a shared computer, or is still valid eighteen months after the person left the client's company. Download links should be issued to an authenticated user and expire shortly after, so possession of a link is not the same thing as permission.

Nobody tests it as two different people at once. The build is checked while logged in as an administrator, everything looks right, and it ships. The bugs that matter in a portal only appear when two real accounts exist simultaneously — a client seeing a colleague's invoice, a status update posted against the wrong account, an administrator's view leaking into a client's. Every portal we deliver is tested with several genuine accounts, from both sides, before it goes anywhere near your clients.