Client Portal Development Guide
What to build into a client portal, the access control and security decisions that matter, integration requirements, and what portal development costs.
A client portal is a secure, branded space where your customers do for themselves what they currently email your team about: check status, download documents, raise requests and see their data. As one of the most common custom web applications in B2B, the build is usually straightforward. The decisions that matter are who can see what, how identity is handled, and which internal system remains the source of truth.
TL;DR
- Portals reduce support load by moving routine requests to self-serve. That is the business case; measure it.
- Access control is the hard part. Scope every query by account, and enforce it server side.
- Decide early whether the portal reads from your core system live or holds its own copy.
- Document handling, notifications and an audit trail are the three features most often forgotten in scoping.
- Indicative build cost starts around $11,000 for a focused portal, typically 10 to 14 weeks.
What belongs in version one
- Account-scoped dashboard showing the status of whatever the customer cares about: orders, cases, projects, shipments, claims.
- Document access with permissions, covering invoices, contracts, reports and statements, with download logging.
- Request submission, replacing the emails your team currently retypes into an internal system.
- Notifications by email or in-app when status changes, because a portal nobody returns to has failed.
- User management so the customer can add and remove their own colleagues, which removes an entire class of support ticket.
- An audit trail of who viewed and downloaded what, which becomes essential the moment the data is sensitive.
Access control is the whole security model
Every query must be scoped by account at the data layer, not filtered in the interface. The common breach pattern in portals is an object reference that is not checked: a user changes an identifier in a URL and sees another customer's invoice. Prevent it with server-side authorisation on every request (see how to implement role based access control securely), database level scoping such as PostgreSQL Row Level Security, and an automated test suite that asserts one account cannot read another's records. Run those tests on every deploy, and consider a periodic security audit to catch regressions.
Identity: how customers sign in
| Approach | Fits | Notes |
| Email and password with multi-factor | Small business customers, mixed audiences | Simple to run. Require MFA where the data warrants it |
| Magic link | Occasional users who forget passwords | Low friction. Depends on email deliverability |
| SSO with SAML or OIDC | Enterprise customers with their own identity provider | Often required in procurement. Test against Okta and Microsoft Entra ID |
| Delegated admin | Any portal with multiple users per customer | Let the customer manage their own users rather than raising tickets |
Live data or a copy?
Reading directly from the system of record keeps the portal always accurate but couples its availability and performance to that system, which is risky when the source is an older ERP. Holding a synchronised copy gives you speed and resilience but introduces staleness and a sync to maintain. The trade-offs here mirror the choices in multi-tenancy: database per tenant vs shared schema. A common middle path is to read reference data from a copy refreshed on a schedule, while transactional actions write straight through to the source with idempotency protection.
Integration requirements to scope early
- The system of record for the data on display, with its API or export mechanism named. Our API integration services cover how we connect these.
- Document storage, and whether files are served through signed time-limited URLs rather than public links.
- Notification delivery, with a provider chosen and bounce handling considered.
- Identity, including whether any customer will require SSO in the next twelve months.
- Analytics, so you can prove the portal actually reduced inbound requests.
Cost and timeline
| Scope | What it includes | Indicative from | Window |
| Focused portal | Dashboard, documents, requests, notifications, one integration | $11,000 | 10 to 14 weeks |
| Partner or reseller portal | Co-branded surfaces, deal registration, training content, CRM integration | $11,000 | 10 to 14 weeks |
| Enterprise portal | SSO, SCIM, custom roles, multiple integrations, audit export | $38,000 | 14 to 20 weeks |
How to know it worked
Measure the inbound requests the portal was meant to absorb, before and after. Track adoption per customer account rather than in aggregate, because one enthusiastic account can hide broad non-use. Watch which pages people return to; that tells you what to build next far more reliably than a feature survey. The Recharge utility reseller platform is an example of a portal built on these principles through our B2B software development services.
Frequently Asked Questions
What is client portal development?
It is the build of a secure, authenticated space where your customers access their own data and complete routine tasks themselves. Typical features include a status dashboard, document access, request submission, notifications and user management. The defining requirement is that every view is scoped to a single account.
What features should a client portal include?
Version one should cover an account-scoped dashboard, permissioned document access, request submission, status notifications, customer-managed users and an audit trail. Anything beyond that should be driven by what your support inbox actually receives, rather than by a feature list from a competitor's marketing page.
How much does a client portal cost to build?
A focused portal with one integration typically starts around $11,000 and runs 10 to 14 weeks. An enterprise portal with SSO, SCIM, custom roles and multiple integrations starts around $38,000. Integration count and identity requirements move the number far more than screen count.
How do you keep one customer from seeing another's data?
Scope every query by account at the data layer rather than filtering in the interface, enforce authorisation server side on every request, and use database level controls such as PostgreSQL Row Level Security. Add automated tests that assert one account cannot read another's records, and run them on every deployment.
Should the portal use SSO?
If you sell to enterprises, expect to need SAML 2.0 or OpenID Connect eventually. For smaller business customers, email and password with multi-factor authentication is usually acceptable. Design the identity layer so SSO can be added without reworking user records, even if you do not launch with it.
Should the portal read live data or a synchronised copy?
Live reads are always accurate but tie your portal's availability to the source system. A synchronised copy is faster and more resilient but can be stale. A practical pattern is reading reference data from a scheduled copy while writing transactions straight through to the source system with idempotency protection.
How long does it take to build a client portal?
Ten to fourteen weeks is typical for a focused portal, assuming the source system has a usable API and your team is available for weekly reviews. Enterprise portals with SSO, provisioning and several integrations run fourteen to twenty weeks.
Can a portal be added to an existing system?
Usually yes. The work is exposing the right data safely rather than rebuilding the core system: an API layer over the existing database or application, an authorisation model for external users, and a separate front end. Where the core system is old, an intermediate service is often safer than opening it directly.
Thinking about a client portal?
Book a free 30 minute call. Bring the three requests your team answers most often by email, and we will scope the portal that removes them.