What we learned building our own client portal with AI

We tell clients to start with the job that's eating their time. So we took our own advice, and ours wasn't hard to spot: endless email trails and chasing invoices.

Projects lived in Monday.com, conversations in Outlook and payments in Stripe. What we wanted was a single place for every part of a project, where deadlines could be viewed and managed easily.

So we built the Just Creative People Client Portal, using Claude Code to do much of the heavy lifting. Think Monday.com plus Outlook plus Stripe, all in one place. (Stripe still handles the card payments, but nobody has to go anywhere else to use it.)

Clients can now sign agreements online, approve each stage, pay by card or bank transfer and see exactly where things stand. Here's what we learned along the way, including the embarrassing parts.

Lesson 1: Build a fake one first

Before touching a real database, we made a clickable prototype running on dummy data, with logins for an admin, a client and a freelancer. It didn't store anything real, but we could walk through every screen as each type of person.

It changed our thinking quickly. Features that sounded essential turned out to be fussy, and questions we hadn't considered came up straight away. Who is allowed to sign? What can a freelancer see? What happens if you remove someone who still has something to sign?

AI makes this kind of prototype cheap. If you're considering a custom tool, this is the step we'd never skip.

Lesson 2: The rules are harder than the screens

AI can produce a good-looking page in minutes. The hard thinking is in the rules behind it, and those were ours to decide.

For the portal, that meant:

• Clients see only their own projects.
• Freelancers see the projects they're assigned to, with costs and payments hidden.
• Signed agreements can't be edited afterwards. Changes to the scope go through a change request.
• Every signature and sign-off leaves a record.

A model can write the code for rules like these. It can't tell you what they should be for your business. Get them written down before anyone builds anything.

Lesson 3: Templates weren't the answer

We planned to create tidy brief templates for websites, shops, branding and automation. Then we faced the obvious: no two of our projects are alike, and a website brief forced into a template helps nobody.

So briefs are now bespoke. We write notes on a project and AI helps draft a brief from them, including tailored stages, deliverables and what's out of scope. Two rules keep this safe. AI never invents a fee, so prices only come from our notes. And anything it has inferred rather than been told is flagged for us to review before a client sees it.

If you ask AI to fill the gaps, it will fill them, confidently. You need a way of seeing which parts it made up.

Lesson 4: The bug that looked like everything was fine

Here's the embarrassing one. Early on, a small coding mistake meant that the buttons that saved things silently failed. Every button. Nothing crashed and the screens looked perfect.

Our early tests hadn't caught it, because they only checked that screens displayed properly. Nobody had asked them to actually press the buttons and check that the data had changed.

AI-written code can look finished long before it works, and it's easy to be taken in by something this polished. Now we click-test anything that saves, signs or pays. Test what the tool does, not how it looks.

Lesson 5: The dull stuff takes the time

The interesting features came together fast. Then came everything else: email that actually lands in inboxes, sending limits, sign-in links, testing payments, moving from a sandbox to the live system. During testing, we hit a sending limit on the email service we'd started with and had to move to a different one.

None of this makes for a good demo. All of it decides whether a real client can actually use the thing. If someone quotes you for a custom tool, ask how they handle it.

Lesson 6: Just because you can doesn't mean you should yet

We built recurring Direct Debit payments, then paused them, because no client needed them yet. It wasn't a waste, but it was a nudge. When building gets this quick, it becomes tempting to add everything. Each extra feature still has to be tested, supported and explained.

Build what the next real project needs.

Lesson 7: AI drafts, specialists check

AI can draft a set of standard terms that reads well. That's a starting point, and reading well isn't the same as being right. Terms, tax and anything with legal weight should go to someone qualified. We'd say the same about any tool you build around contracts or money.

Should you build your own?

For most businesses, the first answer should be no. If an off-the-shelf tool does 90% of what you need, use it. Custom tools still need upkeep, however quickly they were built.

A custom build starts to make sense when:

• the process is central to how you make money
• you're bending yourself around software that doesn't fit, or paying for lots of tools to do it
• you can clearly describe the rules
• someone will own it after launch

That's how we approached the Google Ads Campaign Checklist for Cambridge Xyz, a shared system where clients fill in their brief through a private link and the team signs off every check before and during a campaign. It's a specific process, used repeatedly, and it was worth building.

The short version

AI changed how much it costs to try an idea. It didn't change the need to think clearly about how your business works, or to test things properly. Those parts are still on us, and that's why our strapline is what it is. Human ideas. AI muscle.