Decision guide
A customer portal sounds simple: a login where customers can see orders, documents, status and maybe place requests. In practice it's one of the most misunderstood B2B products — because the word covers everything from a password-protected SharePoint folder to a full multi-tenant product with roles, SSO and ERP integration.
We build customer portals when that's the right answer. We also say no when it isn't. This is the framework we use ourselves before anyone draws screens.
TL;DR
Key takeaways
- A customer portal is worth building when it moves repeated manual work off your team — not when it merely looks modern.
- If the need is "file sharing" or "status updates", SharePoint, HubSpot or a ticketing system is often enough.
- The threshold is when customers must act on your data: orders, permissions, per-contract documents, approvals.
- Auth, roles and data isolation are the core — the UI is the cheap part. Plan those first.
- Start narrow: one flow that saves real time. Expand when usage is proven, not when the backlog is long.
What a customer portal actually is
Strip the word down to the function: an authenticated surface where external users — customers, partners, resellers — see and act on data that is theirs. That can be orders, invoices, support cases, contracts, stock status, booking slots, or a mix.
What separates a portal from "a login on your website" is ownership of the data and the rules around it. Each user may only see what belongs to their organisation. Actions must be logged. Permissions must be revocable. That's why portals often grow out of a CRM or ERP need — not out of a design wish.
If you can describe the need without the words "organisation", "role" or "permission", you probably don't need a portal yet. You need a better page, a better email flow, or a standard tool.
Standard tool vs. your own customer portal
Standard tool
HubSpot, Zendesk, SharePoint, Shopify customer accounts, portal apps in your ERP.
- Fast to launch — configuration, not development
- Support, updates and security patches included
- Works well for support, files and simple status flows
- You adapt to the tool's data model
- Deep integrations and custom flows quickly become expensive workarounds
Your own customer portal
A login built for your business — typically Next.js with your data as source of truth.
- Flows that match how you actually work
- A role model and data isolation you own
- Integrations to ERP/CRM without forcing data into a foreign model
- Can grow into a product (white-label, multi-tenant) later
- Requires ownership: operations, auth, changes over time
When is which the right call?
The left column is your situation — the right is what we typically recommend.
Your situation
Customers mostly ask about case status and want a place to write in
Our recommendation
Zendesk, HubSpot Service or similar. A portal doesn't fix a support-process problem.
Your situation
You share contracts and files, and access control is "send a link"
Our recommendation
SharePoint, Drive or a DMS with real folder permissions. Don't build file sharing yourself.
Your situation
Customers need to see orders, invoices or stock status from your ERP
Our recommendation
Customer portal with the ERP as source of truth — or the ERP vendor's own portal if it covers the need.
Your situation
Partners or resellers must order, approve or see their own prices
Our recommendation
Your own portal. Standard B2B apps rarely cover your pricing and approval logic cleanly.
Your situation
You want "an app for customers" without a concrete flow that saves time
Our recommendation
Wait. Define one manual flow you want to remove first — then build only that.
Your situation
You're torn between a no-code portal and custom
Our recommendation
Prototype the critical flow in no-code for a few weeks. If the data model and permissions break, custom is the honest next step.
“A customer portal that doesn't remove work from your team is just another login you have to maintain.”
What usually gets underestimated
Auth isn't "a login screen". It's invitations, password reset, SSO for enterprise customers, 2FA, session timeouts, and what happens when an employee changes jobs at the customer. If you don't have a plan for that, you don't have a portal — you have a demo.
Data isolation is the second. "Only show my orders" sounds trivial until you have three organisations, sub-departments, external consultants with temporary access, and an admin who may see everything. Row Level Security in Postgres (or the equivalent in your database) is almost always the right place to put the guarantee — not only in the UI.
The third is ownership after launch. Portals change with the business: new ERP fields, new roles, new flows. If nobody on your side (or a vendor under an agreement) owns it, it quietly rusts — and customers fall back to email.
Checklist before you decide to build
If you can't tick most of these, you're probably not ready for your own portal yet.
- We can point to one concrete manual flow the portal should remove (not "better experience" in the abstract).
- We know which source is source of truth for orders/documents/status (ERP, CRM, own system).
- We can describe roles: customer admin, customer user, internal support, maybe partner.
- We've clarified whether customers require SSO (Microsoft/Google/Okta) in v1 or later.
- We have a plan for who operates and changes the portal after go-live.
- We've considered whether the vendor's own portal or a standard tool already covers 80%.
Questions we get again and again
Can't we just use Shopify customer accounts or HubSpot?
Yes — if your needs match what the tool was built for. Shopify customer accounts are strong for orders and re-order in e-commerce. HubSpot is strong for support and content. When you need to blend ERP data, custom approvals and partner roles, standard tools start needing workarounds that over time cost more than a purpose-built portal.
How long does it take to build a customer portal?
A narrow first flow — login, one dataset, one action flow — typically sits in the same range as a smaller product MVP: weeks to a couple of months depending on the integrations. What extends the timeline is almost always unclear source of truth and unsettled roles, not the UI itself.
Do we need a mobile app?
Rarely in v1. A responsive web portal with proper login and "add to home screen" covers most B2B needs. Native apps make sense when you have push-critical flows, offline requirements, or very high daily usage — not because it sits on the wishlist.
What about security and GDPR?
A portal that shows customer data is a processing system. You need data-processing agreements, access logs, deletion/export, and least-privilege roles. Technically we put isolation in the database and auth layer — not only in the frontend — and document it so it can stand up in due diligence.
Can the portal later become a product we sell?
Yes, if you design multi-tenant and branding in from the start — or consciously wait. Many "internal portals" later become white-label. It's cheaper to prepare the organisation model early than to cut it in later. But don't bake marketplace ambitions into v1 if you only need self-service for your own customers.
Considering a portal?
Have a no-strings conversation about the right scope.
We'll help you settle whether the answer is a standard tool, a narrow first flow — or a portal that should be built properly from the start.