Building a Customer Portal on Top of Your Existing System

By Nikola, founder at ZEROX. We build customer portals over the CRMs, ERPs, and billing systems B2B companies already run. Last updated April 2026.

Most B2B companies do not have a customer-facing software problem. They have an inbox problem. The same questions arrive every day, where is my order, can you resend the invoice, what is the status of my project, and each one pulls someone off real work and leaves the customer waiting. Customer portal development is how you turn those repetitive questions into a screen customers can check themselves, without replacing the systems that already hold the answers.

This post is for technical-but-busy teams and the agencies that serve them. It covers the account and auth model, exposing the right data without a rebuild, the self-service actions worth handing over, roles and permissions, and the security you cannot skip. A good portal is a thin layer, not a second product.

Good customer portal development is a layer, not a new system

The most expensive mistake is deciding the portal needs its own database and its own copy of your customer data. It does not. Your CRM, ERP, and billing tool are already the source of truth; the portal's job is to read from them, present a clean view, and occasionally write a controlled action back.

Keep the systems of record where they are. The portal becomes a web app that authenticates users and calls those systems through an API layer you own. Nothing gets migrated, nothing gets duplicated, and when a value changes in the ERP the customer sees it on their next page load.

Start with the account model and auth

Before any UI, answer one question: who logs in, and what may they see? In B2B this is rarely one person. A customer is usually a company with several users, so a login has to map to a customer record, a company in your CRM, an account in your ERP, or a customer ID in billing.

• Decide the unit of access: individual user, company account, or a user who belongs to a company.
• Map each portal user to an ID in your system of record. That mapping is the backbone of everything else.
• Do not build your own password storage. Use an identity provider or an established auth library, and offer SSO or magic-link login where customers expect it.

Get this layer right and the rest is mostly plumbing. Get it wrong and you will refactor everything later.

Expose the right data through an API, without a rebuild

Your portal should never talk to your ERP's database directly. Put a small API layer, a backend-for-frontend, between them. It calls each system through its official API, shapes the response into exactly what the screen needs, and returns nothing more.

That layer enforces three things: only the fields a customer should see, only the records that belong to them, and sensible caching so a dashboard load does not hammer a rate-limited ERP for data that changes hourly. If your system of record is HubSpot, we pull through its API the same way we handle any other HubSpot integrations; the pattern is identical for Salesforce, NetSuite, or a Postgres database you own. This is standard web app development, the discipline is in what you choose to expose, not in the framework.

Decide which self-service actions to hand over

Reading data is the safe half. The value multiplies when the portal can also do things, but writes carry the risk, so pick them deliberately.

• Low risk, high relief: download invoices and documents, track order or ticket status, view project milestones and usage.
• Medium: update contact details, reorder a previous purchase, open a support ticket that lands in your existing helpdesk.
• Handle with care: anything that moves money, changes pricing, or cancels a service. Validate on the server, and where stakes are high, have the portal create a request a human approves rather than writing straight through.

You do not need every action on day one. Ship the two or three that generate the most email, then expand.

Roles and permissions, the part that bites in B2B

Consumer portals have one user per account. B2B portals have an admin who sees every order for the company, a finance contact who should see invoices but not project files, and a viewer who should see almost nothing. Model roles explicitly from the start.

The harder requirement is isolation between customers. One company must never see another's data, even by guessing an ID. We handle the same problem in Loop ELD, our own fleet platform: a carrier admin sees every driver in their company, a driver sees only their own logs, and no carrier ever sees another's records. That check belongs on the server, on every request, the UI hiding a button is not protection.

Security you cannot skip

Authentication proves who someone is. Authorization decides what they can touch, and it is where portals leak. A few non-negotiables:

• Enforce object-level checks: when a user requests invoice 4821, confirm it belongs to their account before returning it.
• Keep an audit log of who viewed and changed what.
• Rate-limit, expire sessions, and treat every value from the browser as untrusted.
• Store as little personal data in the portal as you can. If the ERP holds it, read it live instead of copying it.

What a portal will and will not fix

A portal reliably cuts the repetitive "where is my X" tickets and makes your company easier to buy from. It will not fix bad underlying data, if order statuses are wrong in the ERP, the portal just shows the wrong status faster. Clean the system of record first, or as part of the project.

FAQ

Do I need to replace my CRM or ERP to add a portal?

No. A well-built portal reads from the systems you already run and writes back only where you allow it. Replacing them is usually the most expensive wrong turn.

How long does customer portal development take?

A focused first version, auth, one or two read-only dashboards, and a couple of self-service actions, is typically weeks, not months. Scope grows with the number of write actions and integrations.

Should I build the portal into HubSpot or as a separate app?

Simple gated content and basic account views can live inside HubSpot. Once you need real roles, multi-user accounts, and writes against several systems, a dedicated web app that integrates with HubSpot is more flexible.

Is it safe to expose my internal database to customers?

Yes, if the portal never touches the database directly. An API layer that enforces per-customer access and returns only approved fields is the safe pattern.

Should I build or buy an off-the-shelf portal?

Buy if your needs are generic and you can accept the vendor's data model. Build when the portal has to fit your existing systems, roles, and workflows, the usual B2B reality.

Work with us

If customers keep emailing for things a screen could answer, a portal over your existing stack is one of the highest-leverage things you can build. We scope it, give you a fixed quote, and you own the code. Tell us what systems you run on our /contact page, or read how we approach web app development.