Insights · 11 min read
A practical guide to building a customer portal: the features that matter, build vs buy, identity and data isolation, a realistic timeline, and what it costs.
By GGP Editorial
Every B2B company ends up in the same place. Customers email asking for a copy of an invoice, the status of an order, or a contract they signed last year. Support staff answer the same three questions all day. The data already sits in your ERP or CRM. The customer just cannot see it.
A customer portal fixes that. It is a password-protected area where your customers serve themselves: check an invoice, follow an order, download a contract, pay a bill, raise a support request, update their details. It is the logged-in half of your product, distinct from the public website that sells to new visitors.
This article is for founders, operations leads, and CTOs who have decided their customers need self-service and are weighing an off-the-shelf portal against building one. It covers what a portal actually is, the features that matter, build vs buy, what drives the cost, and how the build should go.
A customer portal sits between your public website and your internal systems. The public site explains what you do and captures leads. The internal systems (ERP, CRM, billing, support) hold the truth about each customer. The portal is the customer-facing window onto a small, safe slice of those systems.
That distinction matters because it decides the architecture. A portal is mostly an identity and integration problem, not a design problem. The hard parts are who can log in, what exactly they are allowed to see, and how you keep one customer's data from ever appearing in another customer's account.
Three things are not a customer portal, and keeping them separate keeps the scope honest. A support forum or knowledge base is read-only content, not account data. A client-facing view bolted onto your internal admin tool is a leak waiting to happen, because internal fields and permissions reach the wrong audience. And a mobile app can be the front end of a portal, but the portal itself is the account, identity, and data layer behind it.
GlobeSoft builds these as part of broader product work. The same identity, integration, and data-isolation thinking goes into the property management systems and financial management systems we have delivered. A portal is where that thinking meets the customer.
Portals get over-scoped quickly. The clean split is between what you need to give customers real self-service and what you add once the model proves out.
| MVP: useful self-service | Later: after customers use it |
|---|---|
| Login and authentication (password, two-factor) | Single sign-on (SAML/OIDC) for enterprise accounts |
| Account profile: view and edit contact details | Multiple users per account with roles (admin, viewer, payer) |
| Invoices and statements: view and download | Online payment of invoices inside the portal |
| Order or request status | Subscription and plan management |
| Document access: contracts, reports | Document upload (KYC, claims, onboarding paperwork) |
| Support request submission | Live chat or an AI assistant |
| Email notifications | E-signature, knowledge base, customer analytics |
The MVP list is small on purpose. A portal that shows invoices, order status, and documents, and lets someone raise a ticket, removes the bulk of the support email you answer today. Everything after that is optimization.
The feature list should follow the operation. A logistics company wants shipment tracking and proof-of-delivery documents. A property company wants tenants to view leases and pay rent. A B2B wholesaler wants catalog, ordering, and credit limits. Same skeleton, different modules. That is the argument for building: the modules follow your business, not a vendor's template.
Off-the-shelf portal products exist and they handle the generic middle well. Salesforce Experience Cloud, Zendesk, and the white-label client-portal tools cover standard needs: a login, a few document folders, a ticket list. If that is all you need, buy. We tell prospects this directly, and it is the short version of our custom software vs SaaS argument.
Building makes sense in four situations.
Your data already lives in systems the packaged tool does not talk to cleanly. If the truth about invoices is in your ERP and the truth about orders is in a custom order system, a packaged portal means a second source of truth and a sync job someone has to babysit. Building the portal onto your systems keeps one source of truth.
You are selling the portal as part of your product. If self-service is a feature you market, then a white-label tool with someone else's branding and per-user pricing is a weak foundation for the product you are actually selling.
Your workflows are specific. Property, finance, logistics, and healthcare all have access patterns and document rules a generic portal does not model. You end up customizing a packaged tool so heavily that you have effectively built one anyway.
Per-user pricing compounds. Portal SaaS is priced per seat or per contact. A company serving thousands of external users reaches a point where the subscription costs more per year than a build, and you still do not own the data or the experience.
Portal cost does not follow the number of features so much as the number of integrations and the identity model. Planning ranges across development shops look like this.
| Scope | What it includes | Typical range |
|---|---|---|
| MVP | Login and two-factor, profile, invoice and document access, order status, support requests, email notifications, one or two integrations | $40,000–$90,000 |
| Mid-tier | Add single sign-on, multi-user roles, online payments, e-signature, several integrations (ERP, CRM, billing), document upload | $90,000–$200,000 |
| Enterprise | Add multi-entity or multi-tenant, custom workflows, an AI assistant, advanced security and audit, migration tooling | $200,000+ |
These are planning ranges, not quotes. The spread is wide because the scope is. The drivers:
Integrations. Each system the portal reads from (ERP, CRM, billing, payment gateway, document store) is a line item, and some third-party APIs are slow to work with. This is usually the biggest driver and the most underestimated.
Identity and roles. A single user type is cheap. Company accounts with roles, enterprise single sign-on, and granular permissions are not. The data model for who can see what is where portals get built wrong or built expensively.
Data quality. The portal only shows what your systems already hold. If customer records are messy or split across systems, you pay for cleanup before the portal is useful.
Security and compliance. Data isolation between customers is non-negotiable. If the portal touches payments, PCI scope arrives. If it holds personal data, GDPR data-subject requests arrive. Our payment gateway integration article covers the payment half.
For a fuller picture of where the money goes, our custom software development cost article walks through it, and estimating a custom software project explains how to keep the number honest. If you want the first release lean, the levers in our MVP cost article apply.
A sensible sequence. Start with the account model and roles. Decide who logs in (an individual, a company with multiple users, or both) and what each role can see. Everything else hangs off this.
Then map the integrations. List the systems that hold the truth: ERP, CRM, billing, documents, payments. Agree which one is the source of truth for each data type, because two systems claiming to own customer status is how portals ship late.
Build the core self-service loop first: login, profile, invoices, order status, document access, support request. That is the MVP, and it is genuinely useful on day one.
Then add payments, e-signature, notifications, and the remaining integrations. Then AI, chat, and analytics, once real usage data exists.
Treat the first release as an MVP. A portal that lets a customer see their invoice and raise a ticket removes most of the support email on day one. A portal that tries to model every workflow plus an AI assistant on day one ships late.
The two failures that end portal projects are both identity failures, and they are silent until they are not.
Data isolation. One customer must never see another customer's data, and this has to be enforced in the data layer, not in the interface. A front-end filter is not isolation. It is a checkbox waiting for a penetration test. Multi-tenant design is a real architectural decision, covered in multi-tenant SaaS architecture.
Authorization. Inside one account, the person who can pay an invoice is usually not the person who can see every contract. Roles have to be modeled from the start, because retrofitting permissions onto a shipped portal is painful.
Audit trail. Log who viewed, downloaded, and changed what. This matters for compliance and for the day a customer disputes something.
The portal also inherits the security of every system it touches. If you integrate a billing system, you inherit its access model. The integration is where most portal security holes actually live, which is the point we make in API integration services.
How much does a customer portal cost to build?
Planning ranges run roughly $40,000–$90,000 for an MVP, $90,000–$200,000 for a mid-tier portal with single sign-on, payments, and several integrations, and $200,000 and up for an enterprise build with multi-entity support and AI. The number follows integrations, the identity model, and data quality.
Should I build a portal or buy one?
Buy if you need a generic login, document folders, and a ticket list. Build if your data lives in systems the packaged tool does not integrate with cleanly, if the portal is a feature you sell, if your workflows are industry-specific, or if per-user pricing has compounded.
How long does a portal build take?
A focused MVP usually ships in three to four months. A full portal with single sign-on, payments, several integrations, and migration typically runs six to ten months.
What is the difference between a customer portal and a mobile app?
The app is one front end. The portal is the account, identity, and data layer behind it. Many companies ship a responsive web portal first and add an app only when customers ask for push notifications or offline use.
Do I need single sign-on?
Not on day one. Single sign-on matters when your customers are enterprises that already use SAML or OIDC. Add it when your customer base demands it, not before.
Can AI be added to a portal?
Yes, and it is the most visible part of the roadmap. An assistant that answers where is my order or explain this invoice is genuinely useful. It only works on top of clean data and correct permissions, which is why it comes last. The same logic is in our LLM integration article.
A customer portal earns its keep on the day a customer finds their own invoice at 9pm instead of emailing your team, and on the day support stops re-sending the same three documents. The public website gets you the customer. The portal keeps them.
GlobeSoft builds customer and client portals as part of our custom software work, usually sitting on top of the ERP, CRM, and payment systems a business already runs. If you are deciding between buying and building, or you have a self-service problem no off-the-shelf tool models cleanly, describe the data and the systems the portal needs to touch. We will help you scope it and give you a number you can trust.
Tell us what you are building and where you are today. We typically reply within 24 hours.
