A portal is the cheapest sales rep, support agent, and ops coordinator you'll ever hire, and most companies build the wrong one. They start from "our customers want a login," ship a glorified PDF download page, and wonder why adoption stalls at 12 percent. A portal that works isn't a place to log in. It's the place a customer goes instead of emailing you, instead of calling your account manager, instead of waiting two days for a status update. If it doesn't remove work from a human's plate, it's a vanity project with a password field.
This is the guide we hand clients who come to us saying "we need a customer portal." It covers the four portal archetypes that account for almost every real build, the build-vs-SaaS decision, the auth and permissions architecture that quietly decides whether your portal survives its second enterprise customer, and concrete 2026 cost and timeline numbers. It's opinionated, because the expensive mistakes here are predictable.
What a portal actually is (and what it isn't)
A portal is an authenticated, role-aware surface that lets an external party self-serve against your data and workflows. The load-bearing words are authenticated (it knows who you are), role-aware (it shows you only your slice), and self-serve (the user accomplishes something without a human in the loop).
A marketing site is not a portal. A static knowledge base is not a portal. A shared Google Drive folder with per-client subfolders is the saddest possible portal, and we've replaced more of those than we can count. The test is simple: if removing the portal would put work back on a human's desk, it's a real portal. If removing it would just inconvenience people, it's a website with a login.
This distinction is a budget question. Portals that genuinely offload work justify six-figure builds because they replace headcount or capture revenue you were leaving on the table. Portals that just "look professional" never earn back their maintenance cost, which runs roughly 15 to 25 percent of the build per year. Build the kind that pays rent.
The four portal archetypes
Almost every portal we build is one of four types, or a deliberate blend of two. Naming yours correctly is the single highest-leverage scoping decision, because each type has a different data model, a different permission shape, and a different definition of "done."
1. Customer / account portals
The customer logs in to manage their relationship with you: view orders, invoices, and shipments; download documents; update billing; open and track support tickets. It's the most common type and the easiest to underestimate, because "let customers see their orders" hides a thicket of edge cases around partial shipments, refunds, multi-contact accounts, and data that lives in three back-office systems.
The defining challenge is data aggregation: the portal is usually a thin face over an ERP, a billing system, and a CRM that were never designed to be queried by customers in real time.
2. B2B / partner portals
Your business customers' employees log in, and now you're modeling organizations, not individuals. A single account might have 40 users across 6 locations with 3 permission levels. Partners place bulk orders, see negotiated pricing, manage their own sub-users, and access tiered resources. This is where naive auth designs die: the moment you have "account admins who manage their own users," you've left single-user thinking behind for good.
The defining challenge here is multi-tenancy and delegated administration, covered in depth below. Get the org model wrong and every future feature fights you.
3. Self-service / support portals
The goal is deflection: let customers solve their own problems so they don't open a ticket. Ticket tracking, knowledge base, account configuration, usage dashboards, billing management. A well-built self-service portal is measured in tickets avoided, and a 20 to 40 percent deflection rate is a realistic, budget-justifying target.
4. Vendor / supplier / operations portals
These face inward in spirit even though the users are external: suppliers submit invoices and accept POs, field contractors update job status, franchisees report numbers. They blur into internal tools, and the line is mostly about who holds the login.
Most real builds are a primary archetype plus a secondary. A B2B partner portal almost always grows a self-service support surface. Name the primary one; it decides the data model.
Build vs SaaS: the decision nobody runs honestly
The first question every prospect asks is "can't we just buy this?" Sometimes yes. The off-the-shelf portal market in 2026 is genuinely good for standard cases, and we tell a meaningful share of inquiries to buy. But the decision is run badly almost universally, because people compare the SaaS sticker price against the build quote and stop there. That's the wrong comparison. (We wrote a whole framework on this for build-vs-buy on internal tools; the logic transfers.)
When SaaS wins
- Your portal is standard. Customers log in, see orders and invoices, download documents, open tickets. If a vendor template covers 90 percent of your needs, buy it. You will not out-build a company that does only this.
- Your back-office systems have native connectors. If your ERP and billing system are mainstream and the portal vendor already integrates with them, you've removed the hardest part of a custom build.
- You need it live this quarter. SaaS is days-to-weeks; custom is weeks-to-months.
- Your branding and UX requirements are modest. You can live with the vendor's look inside your subdomain.
When custom wins
- The portal exposes your differentiated data or workflow. If the way customers interact with you is part of why they choose you, a templated portal flattens you into looking like everyone else.
- Your data lives in systems no vendor connects to, or in a custom data model. The integration work is the build either way; at that point you're paying SaaS rent for plumbing you still have to lay.
- Per-user or per-account pricing punishes your growth. SaaS portal pricing that's fine at 50 accounts becomes a tax on every new logo at 5,000. Run the five-year number.
- You need deep multi-tenancy, custom permission logic, or white-labeling that the vendor charges enterprise-tier money for, or simply can't do.
The honest math includes, on the SaaS side, integration and data-migration work, per-seat fees that scale with you, and the lock-in cost the day you outgrow it; and on the build side, the initial build plus 15 to 25 percent annual maintenance, forever. A $90K portal is really a $90K build plus roughly $18K a year, a $180K five-year decision, not a $90K one. Companies that skip that line item are the ones whose portals rot.
Auth and permissions architecture: the part that decides everything
This is the section most guides skip and the one that quietly determines whether your portal survives contact with a real B2B customer. Authentication (who are you) is mostly solved by buying it. Authorization (what can you see and do) is where portals live or die, and it's almost always custom because it encodes your business rules.
Start with the tenancy model, not the login screen
The first architectural decision is your tenant model, and it's nearly impossible to change later without a migration that touches every query in the system.
For the overwhelming majority of portals, shared-schema with a tenant_id (or account_id) on every table is correct. The non-negotiable discipline: every query is scoped by tenant at a layer that can't be forgotten. Row-level security in Postgres, or a repository layer that injects the tenant filter, not a WHERE clause a developer remembers to add. The most common, most embarrassing portal bug in existence is one customer seeing another customer's data because a single query forgot its tenant filter. Make it impossible by construction.
Then design roles around the org chart, not your codebase
Customer and B2B portals need at least three layers of authorization, and B2B portals need a fourth:
- Tenant isolation (covered above): you only ever touch your own account's data.
- Role-based access control (RBAC): roles like
account_admin,member,billing_only,read_only. Roles are coarse and map to job functions. Most portals need 3 to 6 roles; if you're inventing a tenth, you probably want attribute-based rules instead. - Resource-level / attribute-based access (ABAC): "a regional manager sees only their region's locations." This is where rigid role lists break and you need permissions computed from attributes (the user's region, the resource's owner, the record's status).
- Delegated administration (B2B only): account admins manage their own users, invite teammates, and assign roles, without ever touching your support team. This is the feature that makes B2B portals scale, and the one most-often bolted on too late and painfully.
A concrete pattern from a 40-location dental group we built a B2B portal for: corporate admins saw every location, regional managers saw their cluster, and office managers saw only their own location's supply orders and invoices. That's tenant isolation (the group) plus RBAC (the three role types) plus ABAC (region scoping) plus delegated admin (corporate provisioning office managers themselves). None of it was exotic; all of it had to be in the architecture from week one, because retrofitting region-scoping onto a flat role system is a rebuild, not a feature.
Don't forget the unglamorous auth surface
Audit logs, session management, secure invite flows, and SSO/SAML for the enterprise B2B customers who'll demand it in their first security review. SSO is the feature that closes enterprise deals and the one teams scope last. If any of your target customers have an IT department, budget for SAML up front.
What portals cost and how long they take in 2026
Numbers, because everyone wants them and most guides dodge. These are consistent with our customer portal cost guide ($40K to $250K depending on scope) and our broader custom software pricing. Ranges are wide because a "portal" spans a weekend's worth of read-only dashboards to a multi-tenant B2B platform.
$40K–$250K
Typical portal build range
6–30 wks
Build timeline by scope
20–40%
Realistic support deflection
15–25%/yr
Maintenance as % of build
The biggest cost driver is almost never the portal UI. It's the integrations: getting clean, real-time data out of an ERP, billing system, or CRM that was never designed to be queried by customers. A portal over a modern API-first stack is half the cost of the identical portal over a legacy system that needs a sync layer, a caching tier, and a reconciliation job. Scope the integrations honestly and the rest of the estimate follows.
ROI: how portals actually pay for themselves
A portal earns its keep in one of three currencies, and you should be able to name which one before you start.
- Deflected support volume. A portal that handles a chunk of "where's my order," "send me my invoice," and "reset my account" removes real cost. A 20 to 40 percent deflection rate against a team fielding thousands of monthly tickets is a headcount-equivalent saving that recurs forever.
- Account-manager leverage. B2B portals let one account manager handle more accounts because the routine self-serves. The portal absorbs order-status checks, reorders, and document pulls, so human time goes to the relationship and the upsell.
- Revenue you couldn't capture manually. Partner portals with self-service reordering and visible negotiated pricing lift reorder frequency because the friction of "email the rep" is gone. For a distributor we built for, self-service reordering pulled in a chunk of low-value orders that previously weren't worth a rep's phone call, volume that had simply not existed before.
The pattern across all three: a portal pays off when it removes a recurring human task or recovers a transaction that friction was suppressing. Tie your build to one of those, instrument it, and the maintenance line item justifies itself. Build a portal because "customers expect a login," and you'll spend $90K to make a number on a dashboard nobody opens.
How to scope yours in one afternoon
Before you write a line of code or sign a SaaS contract, answer five questions:
- Which archetype is primary? Customer, B2B, self-service, or vendor. This decides the data model.
- What human task does it remove, and how do we measure that? If you can't name the task, stop.
- Build, SaaS, or buy-the-core-build-the-edge? Run the five-year number with maintenance and per-seat scaling, not the sticker price.
- What's the tenancy and permission shape? Single-user, RBAC, or full B2B with delegated admin and ABAC? This is the architecture decision you can't cheaply undo.
- Which integrations, and how clean is the data? This is your real cost driver. Be honest about how hard your source systems are to query.
If you want help running that, our business portals practice scopes portals against exactly these questions, and a fair number of those conversations end with us recommending an off-the-shelf tool. Browse the cost guides for ranges, or send us the portal you're stuck on.
Frequently asked questions
How much does it cost to build a customer portal in 2026?
A basic customer portal (login, order and invoice views, document downloads, simple ticketing, one integration) runs $40K to $80K and ships in 6 to 10 weeks. A standard B2B portal with an org model, multiple roles, delegated admin, and self-service support is $80K to $150K. Advanced multi-tenant portals with ABAC permissions, SSO, and white-labeling reach $150K to $250K or more. Budget another 15 to 25 percent of the build per year for maintenance.
Should I build a custom portal or buy off-the-shelf?
Buy when your needs are standard and a vendor template covers about 90 percent of them, especially if it natively connects to your back-office systems. Build when the portal exposes differentiated data or workflow, when your data lives in systems no vendor connects to, or when per-seat SaaS pricing taxes your growth. The most common right answer is a split: buy auth, billing, and infrastructure, and build only the differentiated layer on top. Always run the five-year total cost, not the sticker price.
What's the difference between a customer portal and a B2B portal?
A customer portal serves individuals managing their own relationship with you, one user, one account. A B2B portal serves your business customers' employees, which means you model organizations: multiple users per account, location and region hierarchies, delegated administration so account admins manage their own teams, and often negotiated pricing. The org model and permission complexity make B2B portals meaningfully harder to architect, and that complexity has to be designed in from week one.
How long does portal development take?
Six to ten weeks for a basic customer portal, ten to eighteen for a standard B2B portal, and eighteen to thirty-plus for advanced multi-tenant platforms with SSO and white-labeling. The single biggest variable is integration difficulty: pulling clean, real-time data from a modern API-first system is fast; doing the same against a legacy ERP that needs a sync and reconciliation layer can double the timeline.
What's the most important architecture decision when building a portal?
The tenancy and permission model, decided before the login screen. Get tenant isolation enforced at a layer queries can't forget (Postgres row-level security or a repository layer, not a remembered WHERE clause), centralize authorization into a single policy layer instead of scattering inline role checks, and design for delegated administration and attribute-based rules up front if you're serving B2B. These are the decisions that are nearly impossible to retrofit, so they're the ones to get right on day one.