Experience Cloud handles authentication and data access well enough. Custom branding, performance tuning, and modern frontend patterns are where it starts charging you — layers of metadata, CSS overrides, and third-party scripts to deliver what a standard React application would do in an afternoon.
This post walks through a practical path forward using Salesforce Multi-Framework. The approach keeps Salesforce as the backend for data, logic, security, and governance while letting you run standard React code as first-class metadata. It targets teams that already maintain React assets or want to hire from the broader web developer talent pool.
Current State of Salesforce Frontend Development
Most organizations start with Lightning pages or Experience Cloud sites because they ship quickly. The builder tools cover basic layouts and simple flows. Over time the requirements shift. Marketing wants pixel-perfect branding. Support needs faster page loads on mobile. Internal teams request features that sit outside the Lightning component model.
The heavy path usually involves custom Lightning Web Components mixed with Visualforce, external hosting for a React single-page application, and a thick layer of REST or GraphQL middleware. Each extra hop adds latency, token management overhead, and another surface for security reviews. Maintenance becomes a coordination problem between the Salesforce team and the frontend team.
Many teams accept these constraints because the alternative feels like a full rewrite. They continue patching the Experience Cloud site even when the underlying template no longer matches the business direction.
Why a Lighter Native React Approach Often Wins
Salesforce Multi-Framework changes the equation by running React applications directly inside the platform. Your React code deploys as a UIBundle metadata component through Salesforce DX. The application inherits native authentication, GraphQL access via the Data SDK, Apex invocation, and the current user context without external hosting or custom token handling.
This keeps the “brain” of your React application intact while Salesforce manages multi-tenant scaling and security. You avoid the integration tax of standing up separate infrastructure. Code portability improves because standard React patterns, hooks, and state libraries continue to work with minimal changes.
The approach also supports gradual adoption. Existing Lightning or Experience Cloud pages can remain in place while new React modules replace specific sections. That reduces risk compared with a big-bang migration.
How Multi-Framework Works in Practice
Two deployment patterns exist. Internal employee-facing applications use the reactinternalapp template and surface through the App Launcher or the dedicated salesforce.app domain. External customer or partner portals use the reactexternalapp template and connect to an Experience Cloud site for navigation and authentication, though the site itself cannot be edited in Experience Builder.
Both patterns store source, configuration, and routing inside the UIBundle metadata unit. You manage everything through the same SFDX project structure used for Apex and Lightning components. The Data SDK provides .query() and .mutate() methods for GraphQL operations, and Apex controllers remain callable without additional middleware.
Micro-frontends entered developer preview in Summer ’26. You can embed an existing React application inside a Lightning page or Experience Cloud site using a sandboxed iframe and the <lwc-shell> component. Cross-frame communication and CSP configuration let teams iterate independently without touching the host page.
Agentforce Vibes can assist with code generation grounded in your org metadata. The feature does not replace developer judgment but speeds up boilerplate and integration scaffolding.
Honest Limitations and Requirements
The capability requires a Hyperforce org on the Summer ’26 release or later. You enable it through Setup under React Development with Salesforce Multi-Framework. External applications still need appropriate Experience Cloud licenses. Internal applications require the salesforce.app domain toggle and permission sets for access.
LWC remains the stronger choice for deep native integration and component reuse inside Lightning or Experience Cloud. Multi-Framework targets custom single-page applications, reuse of existing React code, or teams that prefer modern web tooling over the LWC framework constraints.
Full replacement of an Experience Cloud site still demands careful planning around authentication flows and metadata dependencies. The platform does not automatically migrate every template or navigation element.
Decision Framework: Light React Stack vs Heavier Custom Build
Choose the lighter Multi-Framework path when three conditions align. First, you already maintain React components or plan to hire React developers. Second, the primary pain points involve frontend performance, branding flexibility, or SEO that standard Experience Cloud templates cannot meet. Third, you want to keep data, security, and Apex logic inside Salesforce without standing up separate hosting.
A heavier custom build outside the platform makes sense under different criteria. Your application requires infrastructure or libraries that Salesforce does not support. Regulatory rules demand data residency in a specific region that Hyperforce does not yet cover. Or the project involves multiple external systems with complex orchestration that would exceed the Data SDK and Apex boundaries.
Teams that start with a small internal application often discover whether the lighter path meets their needs before committing to larger external portals. The metadata-based deployment makes rollback straightforward if requirements change.
Getting Started
Confirm your org meets the Hyperforce and release requirements. Create or update an SFDX project with the uiBundles/ directory structure. Select the appropriate template for internal or external use, then begin development with standard React patterns plus the Salesforce Data SDK.
Deploy the UIBundle and supporting metadata. Grant access through permission sets or profiles. Test authentication flows and data access in a scratch org first. For external sites, configure the Experience Cloud metadata that connects the React application to the site.
Document the decision criteria your team used so future maintainers understand why certain pages stayed in Experience Cloud while others moved to React.
Want help implementing a decoupled React frontend on Salesforce? Book a meeting to discuss your needs. You can also review current service options on the headless Salesforce page.
Read Next
Salesforce Headless 360 — What It Means for SMBs
Salesforce Headless 360 makes CRM API-first for AI agents. SMBs automate workflows without browsers, cutting dev time 40% and scaling ops. Technical guide with checklist.
Why Are Companies Moving From Experience Cloud to Own-Code Portals?
Experience Cloud buys you speed and charges for it in licensing and rigidity. Here's when own-code portals deliver better ROI.
