I Built a Client Portal in a Day. Then I Asked Claude to Review the Whole Thing.

A consulting engagement runs on documents going back and forth. I ask for last year's P&L and an org chart. The client emails them, or doesn't. I send back a deck. Someone asks which version is current. Email is where all of that goes to die.

So the Clarent site now has a client portal: a private place where a client signs in with a link (no password), sees what I've asked for, uploads it, and picks up what I've delivered. I built it in a day with Claude driving and me making the calls. Eighteen pull requests. Then I did the thing I'd recommend to anyone: I asked for a full review of what we'd built, and the review was more useful than the building.

What it does

• Requests. I ask for a document, with a due date and a note. The client sees it in gold at the top of their portal.
• Uploads. Files go straight from the client's browser into private storage. Downloads are links that expire after sixty seconds, and every view is logged.
• Deliverables. I share files with a title and a note. An HTML page (the kind Claude produces when you ask for a "fancy" report) opens inside the portal as a web page, not a download.
• Invoices are next. More on that below.

The portal replaces email attachments and "which version is current?" That's the whole pitch.

The two things I'd copy

Nobody gets an email per file. When I add five requests, nothing goes out until I click Notify client, and then it's one email listing all five. When the client uploads, they get a checkbox: let Brett know. It's ticked by default only when nothing else I asked for is still outstanding. So I hear once the ball is back in my court, not five times on the way there.

Done isn't one state. Closing a request either marks it completed (something was uploaded) or cancelled (nothing was, and I have to say why). The client can cancel too, with their own reasons: we don't have this, already sent it another way, doesn't apply to us. Six months from now I'll know which requests were fulfilled and which quietly died.

Hosting a web page nobody else can see

I wanted to share interactive HTML reports, not just PDFs. The risk is that a web page can run code, and a page running inside the portal could act as the signed-in client. Claude's answer was to run every page in a locked box: its scripts work, charts load from public libraries, but it can't read the client's cookies, reach the rest of the portal or send data anywhere. We tested it with a page that deliberately tried all of those. Everything was blocked; the chart drew.

If you host other people's pages, or even your own, assume the page is hostile and make the box prove it isn't.

The review

By evening the portal worked. It had also been built one feature at a time, each one a reasonable answer to the question I'd just asked. I asked Claude to read the whole thing end to end and tell me what a person seeing it for the first time would find inconsistent.

It found plenty. "Received" meant three different things. The same gold colour meant "your move" on one screen and "waiting" on another. A client's cancellation emailed me instantly while their uploads batched. Reopening a request quietly left its files marked as reviewed. None of it was broken. All of it would have felt sloppy to a real client.

The fix was four rules, applied everywhere:

• Both sides queue, both sides send once. Every email is a summary of everything waiting, never just the last thing that happened.
• One colour rule. Filled gold means your move. Outline gold means waiting on the other side. Green is done. Dashed is written but not sent yet.
• One verb per outcome. Mark reviewed, mark completed, cancel request. The button says what it does.
• One home per file. A document uploaded for a request lives under that request, nowhere else.

Build it piece by piece. Then make someone read it as a whole before a client does.

Two things I learned the hard way

Free tiers pause. The database I'm using pauses after a week without activity, and a client portal is quiet most weeks. The fix is a tiny job that writes one timestamp every Monday and Thursday. It costs nothing and I'll delete it when I upgrade.

Invoicing wasn't what I expected. I bank at Mercury and wanted invoices created from the portal. Creating one through their system needs a key that only works from a fixed internet address, and the hosting I use doesn't have fixed addresses unless you pay $100 a month for them. So the plan flipped: I create invoices in Mercury, as I would anyway, and the portal reads them and shows a pay button. Same result for the client, no new bill for me.

What I'd tell someone doing this

• Decide what counts as "your move" and show only that in colour. Everything else is noise.
• Batch every notification, in both directions. One email per decision, not per click.
• Record outcomes, not just closures. Completed and cancelled are different facts.
• Keep files private by default and log who opened what.
• Ask for the zoom-out review the same day, while it's cheap to change.

If you run a small practice and still move documents by email, ask me what this took. And if you've built something like it and solved the invoicing problem differently, I'd like to hear how.