How to Build a Client Portal With Claude Code Instead of Buying Portal Software

The short answer

Yes, you can build a real client portal with Claude Code: one login per client, a page that shows their documents and where the job stands, and a simple status field you update instead of writing another email. It is not enterprise portal software, and it does not need to be. Building it takes a focused day, not a sprint. The tradeoff is that you own the upkeep afterward, which is the right call for some businesses and the wrong one for others - the rest of this post is how to tell which one you are.

Why I built one instead of paying for portal software

I was managing client documents the way most small teams do: a shared drive folder here, a signed contract emailed there, a status update sent whenever someone asked. Nothing was wrong with any single piece of that, but a new client had no single place to look, and every "where are we on this" question meant digging through three different threads to answer it.

The portal platforms built for this problem are aimed at agencies with dozens of active clients and a team managing permissions across all of them. I have a handful of active relationships, not dozens, and I did not want to pay for a seat-based tool built around a team I do not have. So I asked Claude Code to build the smallest version that actually solved my problem: one login per client, one page showing their documents and current status, and nothing else.

What the portal actually does

How I built it

1. Wrote down the exact three things a client actually checks: what stage the job is at, which documents are ready, what I need from them next. Nothing else made the list.
2. Described that to Claude Code in plain language and asked for a simple web app: a login page, one page per client showing their documents and status, and a way for me to update the status from my side.
3. Reviewed the first version against a real client relationship I was already managing by email, and told Claude Code exactly what was missing, like a plain-language status instead of a percentage bar that meant nothing to the client.
4. Ran it alongside my usual email updates for two weeks before telling a real client to use it instead, so I could catch anything email was quietly doing that I hadn't thought to ask for.
5. Asked Claude Code to add a password-reset flow and a way to immediately revoke a client's access once a project closed, since a portal nobody can lock is worse than no portal.

What broke, and what I would do differently

The first version let any logged-in client edit their own status field, which meant a client could mark their own job "complete" before I had actually finished it. Small mistake, obvious in hindsight, but it's the kind of permission boundary a dedicated platform gets right by default and a first build does not - you have to think to ask for it.

The second issue was file size. My first version choked on a large file a client tried to download, because I hadn't asked Claude Code to handle anything above a few megabytes. If I were starting over, I would ask for read-only client permissions and a real file-size ceiling in the very first request instead of discovering both gaps with a real client watching.

[How to keep business data safe when using AI](/blog/how-to-keep-business-data-safe-when-using-ai) covers the wider version of this problem: what belongs in reach of a tool you built yourself, and what should stay behind a platform that has already been through a real security review.

The One-Login Rule, and when a paid platform still wins

Judge a client portal by one plain test, the One-Login Rule: a portal is working the moment a client never needs a second link or a second email to see where their job stands. The moment you catch yourself saying "and check your inbox for the other file," the portal has not actually replaced anything - it has just added a fourth place to look.

This is also the honest limit of a homemade build. If you have a team that needs different permission levels, clients who need to sign documents inside the portal itself, or more than a handful of active relationships to track at once, a dedicated client-portal platform built for your industry has already solved those problems and is worth paying for. The build here is for a solo operator or small team with a simple status-and-documents need, not a replacement for a real platform once you outgrow that shape.

How I coach members through this build

When a member tells me they're tired of chasing client questions over email, I ask how many active client relationships they're actually juggling. Under half a dozen, with a simple status-and-documents need, a Claude Code build is usually the right first move. Past that, or the moment e-signatures and payments enter the picture, I point them at a dedicated platform instead of watching them rebuild one feature at a time.

The members who get the most out of this did not plan a full portal on day one. They started with the one client relationship generating the most "where are we on this" emails, built the smallest version that fixed just that, and only added a second client once the first version had survived real use.