Client portals

A private door into your business

A client portal is a private, signed-in area of your website where a customer, dealer or rep sees only their own material — order history, invoices, price lists, spec sheets, drawings, warranty forms. It replaces the shared drive and the email thread. We build both sides of that door: the customer view, and the internal one your team works from.

Start your projectAll services

You already have the information. A portal decides who sees which part of it.

The status updates, the signed documents, the job history — it all exists today, spread across inboxes, spreadsheets, and the people who keep it in their heads.

The interesting question is not whether you have it, it's which slice each customer should be able to open at 11pm without asking anyone. We settle that first, then build the screens that carry it.

What's included in a portal build

Real logins, not a shared password

Every person gets a named account, and role-based access decides what they see — access attached to the person rather than to a link that works for whoever holds it. Single sign-on, where staff use an account they already have, is an option.

A wall between every account

One customer's login can never load another customer's records. We enforce that in the database itself, so it holds even if a page or an address bar is tampered with — not just hidden in the interface.

Both sides of the portal

The customer view — documents, job status, invoices, requests — and the internal side your team runs it from: publish an update, upload a file, see what's been opened and by whom.

Documents that stay private

Files live in private storage and are handed out through short-lived links, so a URL that gets forwarded or pasted into a chat doesn't stay open forever.

Notifications people don't mute

Email or in-app alerts when something is genuinely ready, with digests instead of one message per event — so the portal stays a place people trust to tell them something.

A record of what happened

An audit trail of who signed in, what they viewed, and what changed. It answers support questions quickly, and it's the first thing a security review asks to see.

How a portal project runs

  1. 1

    Map the roles

    We list every kind of person who will log in — customer, staff, manager, admin — and write down what each one may see, may change, and must never reach. That list becomes the spec.

  2. 2

    Prototype the main screen

    You get a working version of the primary dashboard with your real data shape in it, so you can react to something concrete before the rest is built.

  3. 3

    Build and try to break it

    We develop the portal, wire up the logins, then deliberately attack the separation — signing in as one account and attempting to reach another's data — and fix anything that gives.

  4. 4

    Roll out in waves

    We bring existing records across, invite a first group of users, and watch closely while they settle in before opening it to everyone.

The same way we run every engagement — how we work →

A good fit if

  • Customers email your team for the same status update every week
  • Sensitive documents are moving around as attachments
  • Different customers should see different things
  • Your team wants one place that shows the current picture
  • People need answers outside business hours

Often paired with a portal

Websites

Fast, beautiful sites built to turn visitors into leads.

Learn more

AI integration

Smart automation and AI tools built into your stack.

Learn more

SOC 2 compliance

Controls, evidence, and readiness for your next security review.

Learn more

Questions we get about portals

It depends on how many roles there are and how much existing data has to come across, measured from kickoff to first users. We'll give you a firm schedule once we've mapped the roles.
The price moves with how many types of user you have, whether it connects to systems you already run, and how much of the data migration we handle, so we'll give you a firm number after the first conversation.
Usually. If your CRM, accounting, or job-management tool has an API — a way for two programs to exchange data directly — the portal can read from it so nobody rekeys anything. Where there's no API, we'll show you the honest options before you commit.
Every request is scoped to the account that made it, and that rule lives in the database rather than in the page, so it can't be sidestepped by editing a link. We then test it by trying to break it ourselves before launch.

Tell us who should be able to log in.

Start your project

A few quick questions — about two minutes.