This is one of the most common architecture decisions we help clients make. The wrong call costs six figures to unwind later, so it is worth taking seriously. Here is how we actually think about it.
A client showed us a roadmap last month with a single line on it that read "launch customer portal, Q2." That one line represents somewhere between $180k and $1.2M of effort depending on the answer to a question they had not asked yet: do we build it on Experience Cloud, or do we build a custom frontend on top of Salesforce?
This is one of the most common architecture decisions we help with, and the wrong call is expensive to unwind. Here is how we actually think about it, without pretending there is a clean rule.
What people mean when they say "custom"
First, a definition. When we talk about a custom portal, we mean a standalone web application, usually built in React or Next.js, deployed on Heroku or Vercel or AWS, that reads and writes to Salesforce through the REST or GraphQL API. Authentication is typically handled through Salesforce Identity, Auth0, or a customer IDP.
Experience Cloud is the other path: a site built inside Salesforce, using Lightning Web Components and the Experience Builder, served from a Salesforce domain (or a custom domain pointed at Salesforce). Users log in with Experience Cloud licenses, which come in several flavors depending on what they need to do.
Both can look great. Both can connect to the same Salesforce data. The difference is where the code lives, who maintains it, and what you are paying for.
Where Experience Cloud is clearly the right call
We default to Experience Cloud when any of the following are true.
The portal is mostly CRUD against Salesforce records.Partners submitting deal registrations, customers logging cases, employees reading knowledge articles. Experience Cloud has standard components for all of this. You write some LWCs for custom flows, configure the rest, and ship in weeks rather than months.
The admin team is expected to maintain it long term.Experience Builder is not perfect, but it lets admins edit pages, change navigation, and update content without pulling in an engineer. A custom React app has no equivalent. Every content change becomes a deploy.
Salesforce Identity and permissions do the heavy lifting.Data sharing in Salesforce is complex. Roles, profiles, sharing rules, sharing sets for portals, account relationships. If your portal needs to respect that model (and most do), Experience Cloud inherits it for free. Reimplementing sharing logic in a custom app is the largest silent cost of going custom.
Volume is moderate and predictable. A few thousand active users, modest pageviews, no viral spikes. The license model is a fixed cost per user, which is easy to reason about.
Where a custom frontend is clearly the right call
We default to custom when any of the following are true.
The portal is a product, not a workflow. If the experience is the thing the company sells (a client portal for a fintech, a patient portal for a healthtech, a booking experience for a travel platform), we build custom almost every time. Product teams need the velocity and flexibility that only a real application framework gives them.
You expect high traffic or public access. Experience Cloud can handle traffic, but the license economics break at scale. A public-access site with a hundred thousand monthly visitors is much cheaper to run on Vercel or Cloudflare than through Salesforce's guest-user model. Once you are above a few thousand concurrent users, the math tilts further.
The UX is ambitious. Custom animations, complex state management, drag-and-drop interfaces, real-time multiplayer features. Possible in LWC, but painful. Modern React or Vue will ship it faster with a better result.
You already have a web team and a design system. If you have engineers who ship production web apps every quarter and a design system they maintain, putting a Salesforce-shaped box in the middle of their stack will frustrate everyone. Let them build the frontend the way they build everything else, and let Salesforce be the backend it is good at being.
The pattern that splits the difference
There is a middle ground that is becoming more common, and we like it for the right project. The frontend is custom (React, Next.js, or similar), hosted outside Salesforce. But the business logic, data model, and automation stay inside Salesforce, exposed through a well-designed API layer. You are essentially using Salesforce as a headless backend.
This pattern works when you want product-quality UX but still want your ops, finance, and support teams to manage data in Salesforce. It costs more than Experience Cloud and less than building a complete custom system from scratch, and it keeps the customer experience under your design team's control.
Salesforce's own direction is pointing this way. The platform is getting friendlier to headless every release. If we were starting a greenfield consumer-facing portal with a product mindset today, this is the architecture we would scope first.
How the cost math actually plays out
A rough frame, based on the engagements we see. Numbers are ranges, not quotes.
Experience Cloud (mid-complexity partner portal, 500 to 2,000 users): $180k to $350k to build, roughly $30k to $90k per year in licenses depending on tier, and ongoing maintenance that an admin plus a part-time developer can handle.
Custom frontend on Salesforce backend (product-grade customer portal, same user scale): $350k to $900k to build, minimal per-user licensing (if any), $2k to $10k per month in hosting and ops, and a small engineering team to maintain it.
The custom path costs more upfront. It costs less per user as you scale. The crossover point is usually somewhere around five to ten thousand users, and it moves depending on how much of your platform depends on the portal.
What we actually ask in discovery
Five questions that pin down the decision.
- How many users, and what is the growth curve over three years?
- Is the portal a workflow layer, or is it the product?
- Who owns the frontend long term: admins, or engineers?
- How much of the UX ambition requires custom components beyond what SLDS gives you?
- What is the data sharing model, and how much of it already lives in Salesforce permissions?
Answer those five, and the architecture usually chooses itself.
The trap we try to keep clients out of
The most expensive mistake we see is starting on Experience Cloud, running into the limits of standard components, and progressively replacing everything with custom LWCs that override default behavior in non-obvious ways. Two years in, you are maintaining a fragile web of overrides, and you are paying for Experience Cloud licenses on top of it.
If the ambition is high enough that you are going to end up writing custom components for every significant page, build custom from the start. You will save money, you will ship a better product, and you will not be fighting the platform every sprint.
The inverse trap is rarer but exists. Teams go custom, reinvent Salesforce's permissions model badly, and spend a year getting back to where Experience Cloud would have put them in a month. If your portal is mostly reading and writing records along a permission structure Salesforce already understands, just use Experience Cloud.
Our default
For most mid-market B2B projects (partner portals, customer service hubs, internal community sites), Experience Cloud wins the cost, speed, and maintainability math. For product companies building a customer experience that is part of what they sell, custom wins. For ambitious consumer or high-volume projects, the headless Salesforce + custom frontend pattern is worth the extra investment.
If you are staring at a "launch portal, Q2" line on your roadmap and you are not sure which of those categories you are in, that is an hour of conversation, not a six-figure experiment. We would rather lose the engagement in discovery than build the wrong thing at the wrong scale.