Custom client portal vs per-seat SaaS

The usual way a client portal starts is a Friday afternoon. Somebody has just spent two hours finding the version of a quote the client approved, which turned out to be in a WhatsApp thread from March, and says there has to be a better way.

So you buy one. Then another, because the first one books meetings but doesn’t do approvals. Then a third for the monthly report. Six months on you have three logins to hand your clients, three invoices to pay, and a person whose real job is copying data between them.

I build the alternative for a living, so weigh what follows accordingly. I’ll try to be fair about when it’s the wrong answer, because it often is.

Where the money actually goes

Per-seat pricing is fine at ten users and uncomfortable at a hundred. The sum is simple. If a tool costs £12 per seat per month and you give it to 40 client contacts and 8 staff, that’s £576 a month, £6,912 a year, and it climbs every time you win a client. (The £12 is an example, not a quote from any vendor. Plug in your own.)

A custom build is the reverse shape. You pay once, a fixed price quoted after a free call, and the running cost is the server and whoever looks after it. Whether that wins depends on one number: your yearly subscription total. If it’s under about £1,500 and nothing about your process is odd, buy the product and stop reading. I mean that.

The case for building gets stronger when the bill is large, or when the subscription is only part of the cost. The rest is the person re-keying things, and the client who never logs in because the login lives on somebody else’s domain with somebody else’s logo.

The question that decides it: who can see what

This is where portals go wrong, and it’s rarely the interface. Every client has to see their own tasks, files and reports and nobody else’s. The common design is one shared database with a tenant_id column on every table and a filter on every query. It works until the day somebody writes an endpoint in a hurry and forgets the filter. Nothing errors. A successful response simply contains the wrong company’s rows.

On the portal I built for an IT firm, I gave every client company its own database file instead. It’s created when the company is added and deleted with it. A query that forgets its filter can only return rows from the one file that’s open, because the others aren’t there to return. I wrote up what that costs at the seams, and it does cost something: schema changes run once per tenant, and reporting across all of them is clumsy.

You’ll see portals pitched with PostgreSQL row-level security for the same job. That’s a legitimate design and I’d use it at a scale where a file per tenant stops being sensible. I haven’t shipped a portal on it, so I won’t tell you it’s what I do. What I do is pick one of the two deliberately and say why.

Under UK GDPR, a client’s staff names, emails and the contents of their files are personal data, and Article 32 expects appropriate technical measures around it. Tenant isolation is one of those measures. It isn’t a compliance certificate, and I’m not a lawyer or your data protection officer. Ask them about the paperwork.

What a portal actually contains

Not much, and that’s the point. Clients log in. They see tasks and what state each is in. They approve things, upload things, and download a report. Staff see everything for their own clients and, if you let them, across clients.

The part people underestimate is roles. On that IT firm’s portal there are six, across two tiers, and I once found a single permission flag guarding two unrelated powers: seeing every client and creating logins. Splitting it took an afternoon. Sort out who’s allowed to do what on a whiteboard before anything gets built. It’s cheaper there.

It also has TOTP two-factor, and a password change signs out every other device. That’s boring and it’s what a client’s finance director will ask about first.

Reports and scheduling, honestly

A monthly PDF report is a scheduled job that reads your numbers, fills a template and drops the file into the client’s area. It’s not magic and it’s not hard. It’s also easy to get wrong in the particular way where the report is generated from last month’s cached data and nobody notices for a quarter, so it wants a check built in.

Scheduling is the opposite. Everybody wants “just sync with our calendar”, and a two-way sync with Google Workspace or Microsoft 365 is several days of fiddly work by itself. I’ll tell you on the call whether a booking form that emails your team does the job. It usually does.

What a build looks like, and what it doesn’t

A small internal tool takes two to four weeks. A portal with several user types and a client-facing side is more like two to three months, in stages you sign off one at a time. At the end the code and credentials are yours and it runs on a server you own, with backups set up and written down. There’s no arrangement where I hold the keys. I run the portal I mentioned on a server of mine, but that’s a separate agreement and you could end it.

I’m one person. If you need ten developers and a project manager, hire an agency. If you need a portal that does four things properly, that’s a fair description of what I’m good at.

Bring the mess

If you’re comparing options, show me what you pay for now and what your staff do by hand around it. Ten minutes with real invoices and real spreadsheets tells me whether this is a two-month build, a bit of glue between tools you already own, or “keep paying for the SaaS”. All three are good answers, and I’d rather you got the right one.

The full offer, including what’s in and out of scope, is on the software builds page. I am based in Barking and Dagenham and take on work across London, Essex and the rest of the UK.