Service · Client Portal Development

Stop running your client relationships through email threads and shared folders you don't control

A custom client portal is a private, password-protected dashboard on your domain where each client logs in and sees exactly their own data: documents, project status, invoices, intake forms, uploaded files. Nothing else. No SaaS subscription that gets more expensive as your client list grows. No third-party platform your clients have to create an account with. No vendor that holds your client data in a format you can't export. Built in pure PHP, deployed on your own hosting, with source code you own outright at delivery. This is infrastructure for your client relationships, not a tool you're renting.

Get a quote See web apps

What a client portal needs to get right, and why each piece matters for your business

A client portal is closer to a piece of software than a simple website. People log in, it stores private information, it controls who can see what, it handles files, and it gives you a behind-the-scenes area to run it all. Getting that right takes careful decisions about how information is stored, how logins are secured, how files are kept safe, how the staff-facing screens are laid out, and when clients get notified. Here is what a well-built portal needs, and why each piece matters more than most people realize before they commission one.

1

A login your clients can use without calling you for help

The login is the front door of the portal, and most portals fail right here: either the security is weak or the experience is confusing. On the security side, passwords are scrambled so they can never be read back, even by us, so a stolen database is worthless to a thief. The login stays valid only on the visitor's own device, repeated wrong-password attempts get locked out automatically instead of letting an attacker keep guessing forever, and a "forgot password" link sends a one-time reset to the client's verified email that expires shortly after. The whole connection is encrypted, so nothing travels across the internet in the open. On the usability side, the login has to be simple enough that a client who logs in once a month and isn't especially tech-savvy can get in without calling you. A confusing login or a flaky password reset means clients just won't use the portal. Both sides matter equally, because a secure portal nobody uses solves nothing.

2

Each client sees only their own data — the most important security promise of any portal

The defining promise of a client portal is that one client can never see another client's information, under any circumstances. This isn't about the screen simply hiding records: every single time the portal looks up information, it checks who is logged in and pulls only that person's records. Not a flimsy filter that only kicks in sometimes. A hard rule on every lookup, so that even if someone tinkers with the web address to try to reach a different account, the portal refuses rather than handing over someone else's records. Files work the same way: each file is only released after the portal confirms the logged-in person owns it, and no file ever sits in a public folder where a guessed web address could grab it. This separation isn't something bolted on after the portal is built. It's a foundational decision made before the first line of code, and it shapes every other choice in the build.

3

Document sharing that doesn't require your clients to have a Dropbox account

The most common reason service businesses want a client portal is document exchange: contracts, deliverables, reports, signed forms, invoices, supporting materials. Today, most of that traffic flows through two broken channels. Email buries attachments, creates version confusion, and has no audit trail of what was sent when or whether the client opened it. Shared Dropbox or Google Drive folders require the client to have a third-party account, give them more access than they need, and have no relationship to your brand or your workflow. A portal document section gives clients a single, categorized view of every file associated with their engagement. You upload from the admin; they download from their dashboard. The access log shows you when they opened it. No third-party account required on either end, and the file history lives in a system tied to your business rather than scattered across someone's email client.

4

Letting clients upload files safely, not just a form that accepts anything

Letting clients send files in is trickier than letting them download. Anything a client uploads comes from outside your business and can't be taken at face value. So every upload gets inspected before it's accepted: the portal checks what the file actually is rather than trusting its name, caps how big it can be, and only allows the file types you've approved. Files that pass get renamed automatically and tucked away where they can't be reached by typing a web address directly, so no client's sensitive document is ever sitting at a guessable web address. The moment a file lands, you see it in your behind-the-scenes area, where you can download it, respond to it, or mark it reviewed. The client gets a confirmation and can see their own upload history. The whole thing runs without email or any outside storage service involved at any step.

5

Project status and milestone tracking that clients check without prompting you

Most "just checking in on status" emails exist because clients have no reliable way to see where their project stands without asking. A project status section in the portal eliminates that email category entirely. You update the admin — current phase, completion percentage, next milestone, any blockers, estimated delivery date — and clients see it in their dashboard without contacting anyone. When you configure a notification for status changes, clients learn to check the portal rather than their inbox. What gets tracked is designed around what your business actually tracks, not a generic project management template: some businesses need a single phase label and a progress bar; others need multiple parallel workstreams each with their own status and deliverable list. The portal is built to match how your work moves through stages, not to force your workflow into categories a tool decided were universal.

6

A behind-the-scenes area built around your daily tasks, not around raw data

A portal without an easy-to-use behind-the-scenes area isn't really a product — it's just a pile of data that needs a developer every time you want to change anything. This is where you spend your time running the portal: adding new client accounts, uploading documents to a client's profile, updating project status, reviewing file uploads, responding to intake forms, closing out accounts when an engagement ends. Each of those needs to be two or three clicks, not a hunt through a technical tool. The screens are designed around the things you do every week — not a generic grid that dumps every piece of raw data in front of you, but a set of screens that matches how you actually manage client relationships. It has its own separate login, so client passwords never get someone into your behind-the-scenes area, and vice versa.

The four hard questions that separate a real client portal from every other website — and why getting them wrong gives you a portal that either leaks data or sits unused

A client portal has to handle things no ordinary website does. It holds private records for many clients at the same time, all in one place, yet each client must see only their own — with zero chance of crossing over into someone else's. It manages logins for outside clients who don't work for you, can't be trained, and log in maybe once a month. It gives your staff a behind-the-scenes area with real controls without exposing the messy details underneath. And it often handles files submitted by clients you can't fully vouch for, storing them safely and serving them back on demand, without ever leaving a sensitive document somewhere it could be stumbled onto. These four demands drive the decisions that separate a portal from a website, and each one has a failure mode that's worse than never building the portal at all.

Keeping each client's data truly separate, not just hidden from view

The classic portal security failure is a dashboard that hides other clients' records on screen but doesn't truly separate them behind the scenes. If the page decides which client's records to show based on a number in the web address, then a client who edits that web address — swapping their own account number for a neighbor's — can pull up that neighbor's documents, invoices, or project status. This is not a theoretical attack. It is a routine thing any moderately curious client might stumble into accidentally or try deliberately. A portal built right decides which records to show based only on who is actually logged in, never on anything the visitor can type into the web address. There is no setting or trick that lets one client reach another client's records. Files work the same way: each file is only handed over after the system confirms the logged-in person owns it, never left sitting in a folder where someone could browse around or guess a file name.

Logging in outside clients: the rules that don't apply to tools your own staff use

Tools your own team uses — staff dashboards, admin panels, back-office systems — are run by employees who get set up by your IT person and use the thing regularly enough to learn it. A client-facing portal is the opposite. The people logging in are outside clients who were never trained on your system and use it infrequently, sometimes once a month, sometimes less. That changes everything about how it has to be built. The "forgot password" link has to just work, with no call to you to finish it. The login can't show vague errors that leave a client guessing whether they even have the right email on file. It can't kick someone out for sitting too long while they read a document. And the welcome email with their login link can't look like spam or show up so late they assume something broke. Every one of these is a rough edge a staff-only tool could get away with, but a client-facing portal can't.

Why files your clients upload need to be handled more carefully than files your staff uploads

Files that your staff uploads to the portal — contracts, deliverables, signed forms — are trusted. You control what goes in. Files that clients submit come from outside your business and can't be taken at face value, and that difference matters at every step of how an uploaded file gets handled. The system has to inspect what a file actually is, not just what its name claims, because a harmful file can be dressed up to look like a harmless one — and the portal needs to catch that and reject it. Uploaded files get renamed automatically so one client can't overwrite another client's file by uploading something with the same name. They're tucked away where they can't be reached by typing a web address directly, and handed over only after the system confirms ownership. There's a firm cap on how big an upload can be, set deliberately by us rather than left to whatever loose default the hosting company happened to ship with.

Building the staff side around real tasks, not around a wall of raw data fields

A behind-the-scenes area that throws every piece of stored data at you as an editable field isn't usable — it's a technician's tool with a login screen bolted on. The things a service business actually does back there are few and repetitive: add a new client, upload a document to their profile, update a project status, mark an intake form reviewed, close an account when an engagement ends. None of those are helped by a sprawling, do-anything interface. What helps is a set of screens built around the handful of actions you take most, organized around each client's record rather than around the raw data. Uploading a document to a client should take three clicks from the client list: open their record, click upload, pick the file. Not: dig through a list of documents, create a blank entry, hunt for the right client in a dropdown of meaningless ID numbers, fill in a file location, save. That difference is the difference between a staff area people use without thinking and one that needs training for every new hire and still generates confused questions from perfectly capable people who just find it hostile.

How a client portal fits into your business's client acquisition and retention flow, and why the operational case undersells the full value

Most conversations about client portals focus on the operational benefit: fewer emails, faster document exchange, less time spent on status updates. For a busy service business, it adds up quickly. But the operational case undersells the value significantly, because a well-designed client portal also affects your acquisition funnel in ways that are less obvious and substantially more durable.

The service businesses that commission client portals share a common acquisition pattern. Prospective clients find them through referrals, organic search, or professional networks. They visit the website, assess credentials and portfolio, and then form a judgment about whether working with this business will be organized and professional. That last step is where a portal shifts the picture. When you can tell a prospective client during a sales conversation that they will have a private dashboard where they can see every document related to their engagement, track project status without emailing you to ask, and pay invoices without logging into a third-party system, that signals differentiation. It says this business runs on infrastructure, not improvisation.

For clients who have worked with disorganized service providers before (and most have), that signal is meaningful. The "can you send me the contract again? I lost it in email" experience is universal. A business that has clearly solved that problem before the engagement begins demonstrates operational competence at the moment a prospect is deciding who to trust with a meaningful piece of work. This is not a nice-to-have; it is a conversion factor.

The acquisition funnel for professional services commonly breaks at a specific point: not awareness, not consideration, but the engagement stage, after a client is already working with you. Most service businesses lose clients not because the work was bad, but because the engagement felt disorganized. They couldn't find the document, they didn't know where the project stood, they had to ask for an update and felt like a burden for asking. A portal eliminates that friction category entirely. The result is clients who are more satisfied, who refer more readily, and whose engagement history lives in a system that makes your business look like it has operated at this scale for years.

The retention dimension is worth examining specifically. Clients who use your portal regularly — who check project status there, download deliverables from it, submit requests through it — are more embedded in your workflow than clients who interact with you only through email. Their history, documents, and communication record are organized in a system tied to your business. The switching cost of moving to a different service provider increases meaningfully when a client has a working relationship with a tool that serves them well. That stickiness is not manufactured — it is the natural result of providing something useful that clients come to rely on, the same way clients stay with accounting software they like rather than switch to something they'd have to re-learn.

The funnel fix a portal delivers most directly is the chronic "following up on status" exchange. Clients don't send those emails because they're high-maintenance; they send them because they have no other way to know where things stand. A portal that shows current status, next milestone, and estimated delivery gives clients the information they need without requiring them to interrupt your work to get it. That one change usually saves several hours per week for a service business with a meaningful client roster, and the savings compound as the client list grows.

Why a SaaS portal tool stops working when your client list grows or your workflow doesn't fit the platform's assumptions

SaaS client portal platforms (Clinked, Moxo, Client Portal, HubSpot's portal module, the portal tab in your project management tool) solve a real problem for businesses with standard workflows and small client lists. If your data model maps onto what the platform built for, and you can live with the monthly per-seat pricing forever, they work. Most businesses that are evaluating custom development have already discovered at least one of four reasons why the SaaS option stopped being acceptable.

The data model mismatch. SaaS portal tools are built around a set of assumptions about what client data looks like: tasks, files, messages, invoices, maybe a timeline. If your client relationships involve data that doesn't fit those categories cleanly (a permit-tracking contractor who needs clients to see specific inspection phase statuses; an accountant whose clients need reconciliation status broken out by account type; a web developer whose clients track multiple project phases each with separate deliverables and approval gates), the platform's data model becomes a constraint. You spend time bending your workflow to fit the tool instead of having a tool that fits your workflow. That is the opposite of what a client portal should do.

The pricing trajectory. Most SaaS portal tools charge per client seat or per active workspace. At ten clients, the monthly cost is manageable. At fifty clients, it is a meaningful fixed expense. At two hundred clients, the annual SaaS fee may exceed the cost of a custom build at the outset. A custom portal does not get more expensive as your client list grows. You pay once to build it, and adding client 201 costs exactly as much as adding client 10: nothing, because it is a database row you already have infrastructure for. For businesses with a growing client roster, the custom build's total cost of ownership crosses below the SaaS alternative's total cost at a predictable point. The crossover comes earlier than most people expect when they actually do the math.

The branding and domain problem. Most SaaS portals operate at the platform's domain or on a branded subdomain of the platform unless you pay for a white-label tier that may cost more than the base plan. Your clients log into a page that looks like a generic dashboard, not your business. For service businesses where the client relationship is the product (where trust and perceived professionalism are differentiators), that matters. A portal at yourfirm.com/portal, styled to match your site and your brand language, signals that you built infrastructure for your clients. That is meaningfully different from sending a client a link to a platform they've never heard of and asking them to create an account to see their project status.

The vendor dependency problem. When a SaaS company changes its pricing, pivots its feature set, gets acquired, or shuts down, your portal changes whether you want it to or not. Clinked was substantially re-priced after their enterprise pivot. Portal tools built into larger platforms get deprecated when the parent company refocuses. A custom build on your own hosting is not subject to any vendor's decisions. The code is yours, the database is yours, the hosting is yours, and the feature set changes only when you decide to change it. You are not waiting for a platform update to get a feature you need, and you are not discovering that the feature you rely on has moved to a higher pricing tier.

Pricing

Basic portal: secure login and client account management, one primary data type (document access, project status, or resource library), and an admin interface to add clients, upload to their profiles, and manage their records. Starts at $2,800. This scope covers the most common use case: replacing the email-and-shared-folder workflow with a private dashboard where clients see their own documents and current status without contacting you. The admin side is built around the tasks you perform most often, not a generic database interface, but the specific screens you need to manage client accounts and keep their data current.

Mid-complexity portal: multiple data types (documents plus project status plus invoices, for example), safe file upload from clients, client-facing intake or approval forms, basic payment integration via Stripe or Square, or email notification triggers when a document is uploaded or a status changes. Most mid-complexity portals land in the $2,800–$5,000 range, depending on the number of data types and the complexity of the admin workflows. File upload, payment integration, and notification pipelines each add scope and are the most common features that push a build into this tier.

Complex portals: multi-tier role systems with different access levels for different staff roles (project manager, contractor, billing-only), richer information with several connected types of records, connections to outside tools that pull in project data from Asana or payment status from Stripe, or automated notifications that fire only when specific conditions are met. These are scoped and quoted per project after a discovery call. No meaningful ballpark exists without understanding the full feature list and data model. The range between a two-role portal with one external API and a five-role portal with four integrations is substantial, and a flat estimate would be misleading for either.

Managed hosting from $30/month includes SSL certificate provisioning and renewal via Let's Encrypt, nightly backups to a separate location, uptime monitoring with alerts, and one hour of admin-layer changes per month. The managed plan covers routine maintenance that does not require a full project scope every time: adding a new client account type, updating a status label set, adjusting a form field, or responding to a hosting provider's PHP version update. Changes larger than one hour or involving new features are scoped separately as small projects.

All portal work starts with a discovery call to map your current workflow, establish what data types and admin actions are needed, and define the feature list before any quote is issued. Scope drives the price; the discovery call is how scope gets established. Request a discovery call

Client portal questions

A basic portal: secure login, one primary data type such as document access or project status, and an admin interface to manage clients. Starts at $2,800. Portals with multiple data types, file upload and download, payment integration via Stripe or Square, or complex role-based permissions run higher. The upper end for mid-complexity builds is usually in the $2,800–$5,000 range, and portals with multi-tier role systems, rich data models, API integrations to external tools, or notification pipelines are quoted per project after a discovery call. Scope determines the price more than page count: a portal with one data type and a clean admin costs far less than one with five data types, three staff roles, and two external API integrations. A 20-minute discovery call establishes what the build will require.
A client portal is a password-protected section of your website where individual clients log in and see only their own data: project status, documents, invoices, intake forms, uploaded files, and whatever else is specific to their engagement with your business. It is not a shared workspace. It is not a public page with a password. Each client's view is walled off from every other client's: one client can't reach another client's records by editing a web address or guessing a file name. Think of it as a private, branded dashboard that replaces the email thread you are currently using to send status updates, exchange files, and collect documents from clients. The key point is that the separation is enforced deep in the system, not just hidden on screen.
No. Client portals built by ArdinGate use pure PHP with server-side session management: the same stack as every other ArdinGate build. No WordPress, no SaaS portal subscription, no third-party platform your clients have to create an account with, and no recurring per-seat fee that grows as your client list grows. The portal lives on your domain, runs on your hosting, and you own the complete source code at delivery. You are not dependent on a vendor's pricing decisions, feature roadmap, or continued operation. Any PHP developer can pick up the codebase and work in it immediately. There are no proprietary abstractions to learn and no plugin ecosystem that can break when a platform updates.
The whole connection is encrypted, so nothing travels across the internet in the open. Passwords are scrambled so they can never be read back, even by us, which makes a stolen database useless to a thief. A login stays valid only on the visitor's own device, and it's protected so another site can't quietly act on a logged-in client's behalf. Repeated wrong-password attempts get locked out automatically instead of running forever. Each client's data is walled off: every lookup checks who is logged in and returns only that person's records, so a client can't reach another client's data by editing the web address. Files are only handed over after the system confirms the logged-in person owns them. There is no public folder a client can browse or guess file names in. See website security basics for a detailed breakdown of each of these patterns and what they protect against.
A basic portal with secure authentication, one primary data type, and an admin interface generally takes 2–4 weeks from signed scope to launch. A mid-complexity portal with multiple data types, file upload and download, client forms, and basic payment integration runs 4–6 weeks. Portals with multi-tier roles, complex data models, third-party API integrations, or email notification pipelines are scoped per project, but most fall in the 6–10 week range. The timeline is confirmed during the discovery call once the full feature list is defined. Content availability on your end and revision cycles on the admin UX are the most common factors that extend timelines, not the development work itself. Portals where the admin workflow is fully defined before build starts tend to come in at the low end of the range.
You get the complete source code at delivery: every PHP file, every SQL schema, all CSS and JavaScript, and the server configuration. Your database is on your hosting account under your control. There is no vendor holding your data in a proprietary format, no export tool you have to request access to, and no migration fee when you want to move hosts or switch developers. Any PHP developer can pick up the codebase immediately. Standard, widely-used technology, with nothing proprietary to lock you in. If you stop the managed hosting plan and want to move everything to a new host, it's a routine copy of the files and a database export, not a vendor negotiation. You are not renting access to your own clients' data, and your ability to move it does not depend on your continued relationship with the developer who built it.
Yes. File upload is a commonly included feature. Clients upload files through the portal: intake documents, signed forms, assets, photos, supporting materials for a project. Every upload is inspected before it's accepted: the portal checks what the file actually is rather than trusting its name, caps how big it can be, and only allows the file types you've approved. Files that pass get renamed automatically and tucked away where they can't be reached by typing a web address directly. There is no guessable web address that returns a client's sensitive document. Your admin sees the upload immediately after it lands. You can download it, respond to it, or mark it reviewed. Clients see their own upload history and cannot access other clients' uploads. No file in the system sits anywhere a client could guess or browse to.
The portal can connect to other business tools that are built to share data, and most modern software is. Common connections for client portals include Stripe and Square for collecting payment right inside the portal, QuickBooks or FreshBooks for pulling invoice data from your accounting system, Basecamp, Asana, or Monday.com for showing project status from wherever your team tracks work, and email services for automatic notifications when a document is uploaded or a status changes. Each connection adds scope and is quoted after a discovery call. The practical test is whether the tool you use is built to connect with other software. If it is, it can generally be hooked up. If you are not sure whether your tool can connect, bring it up during the discovery call and we can check together.
The admin interface is a separate authenticated section of the portal that only you and any staff you designate can access. Client credentials never grant admin access. From the admin, you can add and deactivate client accounts, upload documents to a client's profile, update project status or milestone data, review file uploads from clients, and respond to intake form submissions. The design is functional rather than polished (it is an internal tool, so the priority is clarity and speed of use, not visual design). You do not need a developer for routine admin tasks. Adding a new client, changing a status, uploading a document, and responding to an intake form are all point-and-click. The admin is built around what you do on a daily or weekly basis, not a generic grid that dumps every piece of raw data in front of you.
Yes, payment integration is an available add-on. Clients can view their invoices inside the portal and pay directly via Stripe or Square without leaving your portal or logging into a separate payment system. Payment status updates automatically once a payment clears. The invoice moves from outstanding to paid in both the client's view and your admin view. Partial payments and installment schedules are supportable with additional scoping. If you already use a billing tool like QuickBooks or FreshBooks, invoice data can be pulled from that system via API so your billing workflow remains unchanged. The portal adds a client-facing view and payment button on top of invoices that already exist in your accounting software. See payment integration for more detail on how Stripe and Square connect.
Yes, and this is non-negotiable. A portal that sends client logins and private data over an unencrypted connection is a security liability, not a working portal. Encryption is enforced for the whole portal, not just hoped for on the login page. Managed hosting plans include the security certificate that turns on the padlock in the browser, set up and renewed automatically so it never lapses unexpectedly. If you are on your own hosting, the portal is configured so every visitor is pushed onto the encrypted connection and browsers refuse to fall back to an open one, even on a first visit. If your existing site is still unencrypted, switching it on before adding a portal is a hard precondition: not optional, not something to defer until after launch.
Role-based access is an available feature, though it adds scope. A basic portal has two roles: admin (full access to all client accounts and data) and client (access to their own records only). A portal with multiple staff roles might add a "project manager" role that can view client data and update statuses but cannot deactivate accounts or touch billing. Additional roles (contractor, read-only reviewer, billing-only access) are each their own scoped addition. The complexity comes from enforcing role boundaries consistently across every data query and every interface element, which is why this is scoped separately rather than included by default in every build. If your workflow requires multiple internal roles, bring the specifics to the discovery call so the scope reflects what you need rather than a generic role system that may not match your team structure.
A custom PHP portal's maintenance needs are modest compared to a WordPress or SaaS-dependent build. PHP version upgrades happen on a multi-year cadence and are straightforward on a codebase without a plugin ecosystem to untangle. SSL renewal is automated on managed hosting so certificate lapses don't happen. Beyond that: structural updates as your workflow evolves (new data type, new admin field, new client-facing section), API integration updates when an upstream tool changes its API (which happens on their schedule, not yours), and new features you decide to add over time. The managed hosting plan at $30/month covers SSL, nightly backups, uptime monitoring, and one hour of admin-layer changes per month: adding a new account type, adjusting a status label, updating a form field. Larger changes are scoped separately as small projects rather than absorbed into a blanket retainer.

See all web design FAQs

Related services: web application development · payment integration · website security basics · custom PHP development · web design overview

Ready to replace the email chain with something built for the actual workflow?

Tell me what data your clients need to access, what you're currently sending them manually, and what your admin routine looks like. I'll scope the right build around what you need — not a generic portal template that bends your workflow to fit its assumptions.

Get a quote