Building Salesforce React apps with AI: how easy is it, really? Pros and cons

For years, the choice for a custom Salesforce screen was Lightning Web Components, Visualforce, or an app hosted somewhere else that called Salesforce through an API. In July 2026 Salesforce added a fourth route: React apps that run on the platform itself. Salesforce calls this Multi-Framework. It reached general availability that month and is enabled in orgs on Hyperforce.

At the same time, AI coding tools have become good at writing React. Put the two together and the pitch is obvious: describe the app you want, get a working screen with real Salesforce data, and skip months of front-end work.

Is it that easy? Partly. AI makes the first draft very fast. Most of the work that remains is about Salesforce, not React: access, security, packaging and maintenance. This post explains how the pieces fit, what is easy, what is not, and gives a straight pros and cons list so you can decide before you build.

What "React on Salesforce" actually means

A Multi-Framework app is stored in your org as a UIBundle, a metadata type that holds your app's source and its built files. Salesforce serves those built files. It does not build them for you, so your tooling must run the build before deploying.

The details that matter:

• Your app runs on its own origin. Employee-facing apps are served from the dedicated salesforce.app domain, so the browser's same-origin rules keep one app from reading another's cookies or storage.
• Data comes through the Platform SDK. The Data SDK (@salesforce/platform-sdk) queries and changes records with the User Interface API's GraphQL support. It handles the session, so the app has no tokens to manage. Object-level security, field-level security and sharing rules apply on every request, so a user only sees what they could see in Salesforce anyway.
• Custom server logic still lives in Apex. The app is the browser side. If you need logic that GraphQL cannot express, you write an Apex REST class and call it from the app.
• It reaches users through the App Launcher. An internal app needs a Custom Application that points at the bundle, plus a permission set that makes the application visible.
• You need Hyperforce and the right API version. Salesforce says Multi-Framework is available on Hyperforce orgs on Summer '26 or later, and independent write-ups report that a project needs API version 67.0 or higher.

If you know LWC, most of the ideas carry over: components, props, events, reusable pieces. What changes is the tooling around them: npm, a bundler, React's state hooks and routing, and a separate package file inside the app folder.

Where AI genuinely helps

AI is good at the parts of a React app that are repetitive, well documented and easy to check:

1. Scaffolding. A layout, a header, routes, a list page, a detail page and a form. This is the work that used to take days.
2. GraphQL queries. Given your object and field names, AI can write the query and the types for the result. The shape of the UI API's GraphQL (every field wrapped in a value, lists as edges) is awkward at first, and AI handles it well.
3. The states people forget. Loading, empty and error views, and pagination.
4. Styling. A consistent, responsive screen with a component library.
5. Iteration. "Make the table sortable", "add a filter for owner", "show amount in the user's currency".

The pattern that works is to give the AI your org's real schema before it writes anything. A query written against a guessed field name fails at runtime, not at build time. Whatever tool you use, make sure it can read your objects and fields first.

Where AI does not help much

The risky parts are not the screens:

• Access. The app shows only what the running user may see. A field that the user's permission set does not grant comes back empty or errors. AI cannot know your permission model unless it is shown it, and "it worked for me, an admin" is the classic failure.
• Content Security Policy. One independent write-up reports that every external domain (fonts, CDNs, hosted images) is blocked at runtime unless a CspTrustedSite record exists for it, with no wildcards and HTTPS only. An AI-generated page that loads a font from a CDN will look fine locally and break in the org.
• Local is not production. You can preview the app on your own machine against real org data, which is a real advantage over LWC. A page that works locally can still fail once deployed, because of the API version, CSP or missing access.
• The wiring metadata. The Custom Application and permission set must exist before anyone can open the app. A deploy can succeed and still leave a screen nobody can reach.
• Judgement. Whether to build the screen at all, what to do with errors, and who owns it in two years.

Pros

You get the React ecosystem on the Salesforce platform. Routing, component libraries, charting and form tooling are all available, and hiring is easier: far more people know React than know LWC.

No separate hosting or login. Previously a React front end meant hosting it, building OAuth, and running a proxy. Here the app lives in the org, uses the user's session and respects their permissions.

Security is inherited, not rebuilt. Field-level security and sharing apply to every GraphQL call, and each app runs in its own browser origin.

A faster path from idea to working screen. With AI generating the scaffold and queries, a custom app can reach a reviewable state in an afternoon.

Better local development. You can run and debug the app on your own machine with live data, instead of deploying to see every change.

It fits the headless direction. Salesforce's Winter '27 notes put Multi-Framework alongside MCP tools, the CLI and APIs under a single "Headless Toolkit" theme. The same org capability can be reached from an app, an agent or a script.

Room to grow. Winter '27 adds Angular alongside React, a way to embed your app inside a Lightning page as a microfrontend (beta), packaging with second-generation packages, and a New Multi-Framework App option in App Manager.

Cons

It is young. It reached GA in July 2026, and there was a breaking change from beta to GA (a new package name, separate query and mutation calls, and a changed app target). Expect more movement, and expect some AI tools to generate beta-era code.

It is mostly for standalone apps. An internal React app is opened from the App Launcher as its own application. It is not a drop-in for a single component on a record page the way an LWC is. The Winter '27 microfrontend option (beta, for internal apps served from the salesforce.app domain) starts to close that gap, but it is a beta.

You are taking on a front-end codebase. React needs a build step, dependency updates, security patching of npm packages and someone who understands it. A Flow or an LWC has none of that overhead.

Server logic is still Apex. There is no server runtime in the bundle. If your design needs secrets, scheduled work or integrations with external systems, those live in Apex, Flow or elsewhere.

Setup is fiddly. Two package.json files, a build before every deploy, CSP entries per domain, an API version minimum, and the Custom Application and permission set. None of it is hard, but together it catches newcomers.

Hyperforce only. If your org is not on Hyperforce yet, you cannot use it.

Governance gets harder. Admins can review a Flow in Flow Builder. Reviewing a React codebase takes a developer. Decide who owns the app, who reviews AI-generated code, and how it is tested before it reaches production.

AI can produce confident, wrong code. Invented fields, deprecated SDK calls and missing error handling are common. The cost of a wrong answer is not a failed demo. It is a screen that shows the wrong data to the wrong person.

Licensing needs checking. Salesforce's GA announcement does not cover pricing. Confirm what your licences allow for the users who will open the app.

When to choose React, LWC or Flow

A good test: if a Flow or a standard Lightning page does 80% of the job, start there. React earns its place when the user experience is the product.

A sensible way to build one with AI

1. Write the brief like a spec. Who uses it, which objects and fields, what they can change, and what happens on an error.
2. Ground the AI in your org. Give it the object and field names, and the permission sets involved.
3. Start from a working template, not an empty folder. A template that already reads live data with the Data SDK avoids a whole class of setup mistakes.
4. Build after every change. A build catches broken imports and syntax errors in seconds. Do not wait for deployment to find them.
5. Test as the user, not as yourself. Open the app with a user who has only the permission set you intend to give.
6. Deploy to a sandbox first. Check the app opens from the App Launcher, loads data, and respects access.
7. Review the code like any other release. Someone who understands both React and Salesforce security reads the data calls before production.

Where the orgadmin.ai Development Studio fits

The Development Studio is built for the loop described above. For React apps it can:

• Start an app from a small working template (React with React Router, Tailwind and ready-made components, with a home page that reads live Salesforce data through the Platform SDK and has loading, empty and error states).
• Add the Custom Application and the access permission set, so the app can be opened from the App Launcher once deployed.
• Use your org's real objects and fields as context while the AI writes queries, instead of guessing.
• Build the app the way a deploy will, and report each error with its file, line and column, so the AI can fix it and build again before anything goes near your org.
• Deploy through the Metadata API, with the usual validate-first and test-level choices described in quick deploy and validate-first. Salesforce needs the built files, so the studio builds the app as part of the deploy.

The limits are worth knowing. The studio build works from a fixed set of packages (React, React Router, the Platform SDK, Tailwind and a handful of UI and utility libraries), so an app that needs another npm package will not build there. It does not run a type-check. The app is front-end only, so server logic goes through Apex. And your org must meet Salesforce's own requirements: Hyperforce, the Salesforce app domain turned on, and a recent API version.

If you prefer to work in Claude Code, Cursor or another AI tool, the MCP server gives those tools the same view of your org.

Bottom line

React on Salesforce is real, supported and getting better quickly. AI makes the first draft cheap. The cost moves to everything around it: access, security, deployment and ownership. That is the right place for the cost to be, as long as you plan for it.

Use it where the experience matters and a Flow or an LWC would be a stretch. Keep it out of places where a standard page would do. And treat AI-generated code as a draft that someone who understands Salesforce reads before anyone else relies on it.

Facts in this post come from Salesforce's developer blog and an independent developer write-up. Multi-Framework is changing quickly, so check the current documentation before you commit to a design.