# Experience Cloud or build your own? > The decision is almost always made on what it costs to build the first version. That is the cheapest year, and the three lines that decide the total are not in the quote. - Source: https://synconai.com/insights/experience-cloud-vs-custom-portal - Publisher: SynconAI (https://synconai.com) - Desk: Experience Cloud - Author: SynconAI Architecture Team, Solution & technical architecture - Published: 23 April 2026 - Updated: 29 August 2026 - Reading time: 8 minutes - Topics: Experience Cloud, Portals, Build vs Buy, Architecture, Identity ## Key points - Year one is the only year in which the custom build looks cheaper. Identity, the security review and maintenance decide the five-year total, and none of them appear in the build quote. - Configuring wins wherever the portal exists to expose Salesforce data and processes to a known audience, which describes most portals. - Custom genuinely wins in three cases: the portal is the product itself, the audience is consumer scale, or a requirement the platform cannot meet. - Building your own means owning authentication, session management, the sharing enforcement Salesforce would have done for you, and every penetration test finding from now on. --- A build-versus-configure decision for a customer portal is usually settled in one meeting, on one number: what it costs to build the first version. That figure is knowable, a development team can produce it in a week, and everybody in the room understands it. It is also close to the least useful number in the decision, because it prices the cheapest year of owning a portal. Salesforce [Experience Cloud](https://www.salesforce.com/service/customer-self-service/portals/) is the configure option: a portal sitting on the platform that already holds the data it exposes, inheriting the sharing model, arriving with authentication built. A custom portal is the build option: a front end you own, talking to Salesforce over APIs, running wherever you choose to run it. Both produce a working portal. They diverge in years two through five, which is where the decision should be made and almost never is. ## The comparison is run on the wrong year Year one flatters the custom build, and it does so honestly. A development team quotes the screens, the API layer and the deployment, and the quote is usually about right for what it describes. Against it sits a licence line that appears immediately, recurs visibly at every renewal and is easy to attack in a budget review. One cost reads as a project and the other reads as a subscription. Projects finish. Subscriptions do not. That asymmetry does most of the persuading before anyone has examined what the two options actually cover. What the year-one view omits is that the licence buys operational capability the build quote does not include and rarely mentions. Identity is scoped in a different document, if at all. The second penetration test is nobody's line item. The steady run of small changes that arrives once real users have the portal is assumed to be somebody's spare capacity. None of this is dishonesty. The build quote answers the question it was asked, which was what it costs to build, not what it costs to keep. ## The five-year comparison, with the omitted lines The exercise worth doing puts both options on a five-year horizon and forces the missing rows onto the page. | Line item | Experience Cloud | Custom portal | | --- | --- | --- | | Front-end build | Configuration, components, theming | Full build, plus the framework choice you will live with | | Authentication | Included: login, MFA, SSO, password reset, session handling | Build it or buy an identity provider, then integrate and run it | | Record-level access | Platform sharing model, enforced for you | Enforced in your own code, on every endpoint, permanently | | Security review | Platform certifications inherited; your configuration is what gets tested | Whole application in scope for every test and client questionnaire | | Platform releases | Three Salesforce releases a year, regression tested by you | Framework, dependency and API upgrades on someone else's schedule | | Ongoing change | Most requests handled at admin level | Most requests need a developer and a deployment | | Key-person risk | Skills available in the Salesforce market | Concentrated in whoever built it | | Accessibility | Base components carry a starting position | Yours to build, audit and defend | Two of those rows do most of the work and neither is usually in the original business case. Authentication is a product rather than a feature. Sharing enforcement is a permanent obligation rather than a one-off implementation. ## Identity is the line that moves the total Login is the part everybody scopes. It is also the smallest part. What follows login is multi-factor enrolment and recovery, single sign-on for the customers who insist on it, password reset that survives a failed inbox, session lifetime and revocation, account lockout, delegated administration so a partner can manage their own users, and a user hierarchy for organisations whose staff join and leave. Each is a fortnight of work and a permanent support surface. Experience Cloud ships all of it because a portal cannot function without it. Buying an identity provider is the sensible answer if you do go custom. Note what it does to the comparison, though: you have reintroduced a per-user subscription. The argument that per-user licensing was the reason to build has quietly lost its own premise, unless the audience is genuinely consumer scale. ::: warn Writing your own authentication is the decision most likely to be regretted. It is not the hard part on day one. It is the hard part every day afterwards, and it is where a breach comes from. ::: ## The security review that never closes A custom portal is application code exposed to the internet, holding customer data. That places it permanently inside the scope of every penetration test, every enterprise client's security questionnaire and every internal audit. The sequence is predictable. The first test produces a list. You fix it. The second test, a year later, produces a different list, because the framework moved, a dependency was added and somebody wrote an endpoint that trusted its input. There is no version of this that finishes, and the annual remediation is a maintenance cost that was never in the build quote. Experience Cloud does not remove security work. It changes what is in scope. What gets examined is your configuration, your sharing rules and your guest user access, rather than your session handling, your input validation and your dependency tree. Salesforce sets out its side of that boundary in its [platform security](https://www.salesforce.com/platform/cloud-data-security/) material, and the boundary is the whole point: on a custom portal, both sides of it are yours. ## Then the person who built it leaves Every custom portal has an author, and for the first year or two that is an advantage. They know why the session handling looks like that, which endpoint is load bearing, and which part of the code nobody should touch on a Friday. Then they take another role, and the knowledge goes with them. What is left behind is a front end written in whatever framework was current at the time, against a Salesforce API version that has since moved on, with tests that may or may not exist. The next developer inherits it cold. Their first estimate for a small change is high, not because they are slow but because they are reading before they are writing, and that premium never fully goes away. The configure option is not immune to this, but it fails softer. Most changes are configuration, the conventions are the platform's rather than one person's, and the skills are available in a market you can hire from. On a custom portal, the market you are hiring from is people who know your framework and are willing to learn your Salesforce data model, which is a smaller pool than either half suggests. The five-year cost of that difference does not appear as a line item. It appears as a backlog that stops moving. ## Where custom genuinely wins Three cases, and they are real. **The portal is the product.** If customers pay for the portal itself rather than using it to reach your business, its interface is your product surface. Product surfaces need their own release cadence, room to experiment, and a design language that answers to nobody else. That justifies owning the stack. **The audience is consumer scale.** Per-user licensing has an obvious ceiling. A membership base in the millions, a public account anybody can register for, a marketplace with an open long tail: at that shape the licensing model is the wrong instrument regardless of how good the platform is. Model it honestly, including the identity provider you will still be paying for. **A requirement the platform cannot meet.** Not a preference for a particular framework, and not a design comp somebody has already approved. A genuine constraint: an interaction model, an offline mode, a performance envelope or an embedded experience the component model will not produce. This case is claimed far more often than it occurs, and the honest test is whether a Salesforce developer who knows the platform well agrees it cannot be built. ::: note Notice what is not on that list: dislike of the default styling, a preference for a particular front-end framework, and a wish to avoid a licence conversation. Those are real feelings and poor architecture reasons. ::: ## Where configure wins, which is most portals Take away those three cases and what remains is the ordinary one: a portal that exists to expose Salesforce data and processes to a known audience. Customers checking a case. Partners registering a deal and reading their own pipeline. Members updating a record and downloading a document. Suppliers looking at an order. For that shape the argument is not close. The data is already on the platform, the sharing model already describes who may see what, the users are already recognised, and most of what people ask for in year two is configuration rather than a deployment. Building a separate front end to reach data you already hold means rebuilding the access control that came with it, and doing it less well, because [the platform](https://www.salesforce.com/platform/) has been getting that specific problem wrong and then fixing it for longer than your team has existed. Once that is settled the work moves to doing the configuration properly, which is a different discipline with its own failure modes. We set those out in [Experience Cloud projects fail on the sharing model, not the theme](/insights/experience-cloud-implementation-best-practices), and the design decisions that follow in [portals people actually finish tasks on](/insights/experience-cloud-portal-best-practices). ## The question that resolves it Ask who maintains the portal in three years, and require a name. If the answer for the custom option is a named team with a funded budget line, a release process and a security testing schedule already running, the build is defensible on its merits and the rest of the comparison can be had honestly. If the answer is the contractor who built it, or an internal developer who has other work, then the five-year cost is already known and it is not the number in the quote. ::: tip Run the five-year table with finance in the room rather than the development team alone. The rows a build quote omits are exactly the rows finance is used to asking about. ::: The decision is not really build against buy. It is whether you want to own an authentication system, a sharing enforcement layer and a permanent remediation queue, in exchange for control you can only turn into value if the portal is the product. Most organisations, looking at that trade honestly, find the portal belongs on the platform they already run.