Services / Web / Customer portals

Give your clients their own login, and take your inbox back

A large share of your team's day goes on telling clients things a screen could have told them: where the job is up to, what was invoiced, when the appointment is, where the document went. A portal answers all of it at three in the morning, and keeps a record of who saw what.

Start the conversation →See the technology

Why it matters

The cost is the wait

Look at what your account managers actually do all day. A surprising amount of it is retrieval: finding a document, checking a status, re-sending an invoice, confirming a date. None of it requires judgement, all of it interrupts something else, and every instance is a client who had to wait for a human to be at a desk.

A portal is the cheapest way to stop that, but only if it is built around your clients' questions rather than your database tables. The failures are easy to recognise: a login screen in front of internal jargon, a list of documents with no dates, a status field that means something precise to your operations team and nothing at all to anyone else. Clients try it twice, go back to emailing, and you have paid for software that improved nothing.

The ones that work start from the ten things clients ask for most and make each answerable in a couple of clicks, with the actions attached, so a client can not only see the invoice but pay it, not only see the schedule but change it. That is also the point at which a portal stops being a cost centre and starts shortening the time it takes you to get paid.

What you actually get

Built to be trusted

A portal is mostly a security and integration project wearing a user interface. Here is what that means in practice.

Sign-in that fits the client, not the developer

Email and magic links for a sole trader, two-factor where it matters, and proper single sign-on for corporate clients whose IT department will insist on it. Enterprise sign-on is frequently the feature that unlocks a large contract, so we treat it as revenue work rather than a nice-to-have.

Permissions enforced where they count

Every request checks on the server whether this person is allowed to see this record. Hiding a button is a courtesy, not a control, and the gap between the two is where most portal data breaches actually come from.

Their data, from the systems you already run

The portal reads your CRM, accounts package and operational systems rather than becoming a fourth place where the truth might live. We agree which system owns each piece of data before anything is built.

Actions, not a read-only window

Pay an invoice, approve a quote, book or move an appointment, upload a document, raise a request, add a colleague to the account. A portal that can only be looked at gets opened once and remembered as a disappointment.

Documents handled properly

Contracts, reports, statements and certificates stored with versions, access rules and expiry, delivered over links that cannot simply be forwarded to somebody who should never have seen them.

An audit trail you can stand behind

Who logged in, who saw what, who changed what, and when. Useful the day a client disputes something, and necessary the day a regulator or an enterprise procurement questionnaire asks.

Where it earns its keep

Same pattern, different desks

Different sectors, same underlying request: let the client see it themselves.

01 · Accountancy & professional services

The document chase that eats January

The problem: Records arrive by email in a dozen formats, chasing them is a manual job someone has to remember, and clients ring to ask whether their return has been filed. Sensitive financial documents sit in inboxes never designed to hold them.
What we build: A client portal with a per-client checklist of what is still outstanding, secure upload, automatic reminders, and a status the client can read without ringing, plus signed approvals and fee notes payable in the same place.
What changes: The chase becomes automatic, documents leave the inbox, and the busiest weeks of the year stop being a scheduling problem for the whole firm.

02 · Property & facilities management

Landlords, tenants and contractors in one place

The problem: Three audiences with three different views of the same building (statements, maintenance requests, safety certificates, job progress), all currently handled by phone calls to a small office that is already at capacity.
What we build: One portal with strictly separated views: owners see statements and compliance certificates, tenants raise and track issues with photographs, contractors see only the jobs assigned to them and close them off with evidence attached.
What changes: Fewer phone calls, a documented history for every unit, and compliance paperwork that can be produced on demand instead of reconstructed under pressure.

03 · Healthcare & clinics

Booking and results without the front desk

The problem: Patients ring to book, ring to change, ring to ask what to bring, and ring for results. The phone goes while the receptionist is with someone in person, and personal information is discussed with whoever happens to answer it.
What we build: A patient portal for booking and rescheduling against the real calendar, pre-appointment forms completed in advance, and results or letters released deliberately by a clinician, with identity verified properly and every access logged.
What changes: A front desk that can concentrate on the person in front of them, fewer missed appointments, and personal data handled in a way that stands up to scrutiny.

The technology

The tools behind it, named

Portals are judged on two things: whether they are secure, and whether the numbers on them are right. The stack reflects that.

6 layers · 31 technologies

The application

Typed end to end, so a change to your data model shows up as an error at build time rather than as a wrong figure on a client's screen.

Next.js
React
TypeScript
Tailwind CSS
tRPC
Zod

Sign-in & identity

From a magic link for a one-person client to full corporate single sign-on for an enterprise IT department that will ask before signing anything.

Auth0
Clerk
Keycloak
Okta
Supabase

Where the data lives

A relational database designed around how your business actually works, with backups we restore regularly to prove they work, because an untested backup is not a backup.

PostgreSQL
Prisma
Drizzle ORM
Redis
Neon

Connecting what you already run

The portal should read your existing systems rather than becoming another place where a version of the truth is kept.

Salesforce
HubSpot
Xero
QuickBooks
Zapier
n8n

Documents, payments & notifications

Statements, contracts and invoices, plus the messages that tell somebody there is something waiting for them.

Stripe
Resend
Cloudinary
Twilio

Security, monitoring & uptime

Alerts to a real person the moment something breaks, dependency scanning on every build, and certificates that renew themselves.

Cloudflare
Sentry
Snyk
Let's Encrypt
Better Stack

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

Ten to sixteen weeks is typical, and it is the integrations, not the interface, that decide where in that range you land.

The ten questions clients actually ask

We start with your inbox and your phone log, not your database. The first version of a portal should answer the questions that genuinely arrive, and very little else.

Data ownership, agreed in writing

For every field on every screen: which system is the master, how often it syncs, and what happens when two systems disagree. Skipping this is exactly why portals end up displaying numbers nobody trusts.

The security model

Who can see what, how identity is verified, what happens when someone leaves a client's company, how long sessions last, what gets logged. Written down, reviewed with you, then encoded as automated tests rather than left as good intentions.

Build the first slice end to end

One complete journey (log in, see the thing, do something about it), working against real data early, so you are reacting to a working portal instead of to a picture of one.

Pilot with real clients

A handful of friendly clients use it while the old route still exists. Their confusion is the most valuable feedback in the whole project, and it is cheap to act on at this stage.

Roll out, and retire the old way

Onboarding emails, a short guide, and, crucially, a date after which the old manual route closes. A portal running alongside the email chase forever saves nobody any time at all.

Before you commit

The questions worth asking

How secure is it, really?

Security is a set of decisions rather than a product, so here is what we actually do: permission checks on the server for every request, encryption in transit and at rest, two-factor available and enforceable, session and access logging, dependency scanning on every build, and a human security review of the sensitive paths: sign-in, permissions and file uploads. For regulated clients we arrange independent penetration testing. What nobody can honestly offer is a guarantee. What we can offer is a system where a mistake is caught, logged and recoverable.

Our clients are not technical. Will they use it?

Some of them will not, and it is better to plan for that than to be surprised by it. Adoption comes from making the portal the fastest route to something the client actually wants (the invoice, the certificate, the appointment) and from a firm date when the old route closes. Expect a tail of clients who still ring, and keep a human path open for them rather than pretending they do not exist.

Can it work with our old system that has no API?

Usually, though the method matters a great deal. Best case there is a documented interface. Common case there is a database we can read from safely, or a scheduled export we can consume. Worst case is screen-scraping or a nightly file, which we will do if we must but will tell you plainly is fragile and will need maintaining. We investigate this before quoting, because it is the single biggest driver of cost in portal projects.

What about GDPR and data-protection obligations?

The portal is built to support them rather than to claim compliance on your behalf: access controls, retention rules, export and deletion of an individual's data, and a log of who accessed what. Compliance is your organisation's responsibility and depends on your policies and processes at least as much as on your software. We build the parts software can be responsible for, and we will tell you honestly where the rest sits.

Do we have to build every feature at once?

No, and you should not. The best portals launch with one or two things clients genuinely want and grow from there. Building the whole imagined feature list before anybody has logged in is the most reliable way we know to spend a large budget on screens nobody opens.

What does it cost to keep running?

Hosting and the database are usually modest. The real ongoing cost is the identity provider (typically priced per active user, so it scales with your client list) and the maintenance of the integrations, because the systems you connect to change without asking your permission. We size both during scoping, give you a monthly figure, and build integrations so that a change at the other end fails loudly rather than silently.

What are your clients always emailing about?

Tell us the five things your team gets asked for most. We will tell you which of them a portal should answer, what connecting to your systems would involve, and where we would start.

Start the conversation →

Explore more

The rest of Websites & Web Platforms

Company websites Online stores Internal tools Web apps & SaaS Redesigns & rescues ← All of Web