An engineer built a React app for the claims team in Claude Code over two weeks. It works. It also runs on a service account with write access to the claims database, and nothing records who changed what. Security will not approve it, and the security team is right.
Custom code has always been easy to write and hard to ship into a regulated company. Retool's new app builder, public since 17 June 2026, changes where that code can land. This piece covers what changed, what stays the same for IT, and what to check before moving existing apps.
Why custom code stalled in review
The code was rarely the blocker. The access around it was.
Getting a custom script, a standalone app, or an AI agent into production meant a trade. Someone granted it broad database access, or ran it outside the audit trail. Security then flagged the same risk each time: an unmonitored process touching too many systems. The request stalled. Teams either accepted a narrower tool or ran the code outside the controlled environment and took on its upkeep.
There was also more than one gate. A new tool has to clear procurement, security, and the platform or DevOps team, each with its own timeline and risk threshold. In companies that already run Retool, the platform has cleared all three. New code that lands inside it extends access IT has already granted, so it does not start a new procurement cycle.
What the new app builder is
Apps in the new builder are React on the front end and TypeScript on the back end. You can write them in three ways:
In Retool's own chat and code views.
In a coding agent such as Claude Code, working through Retool's MCP server or CLI.
In another tool or a local repository, such as Codex, Replit, Lovable, or v0, then imported.
On import, Retool maps the app's data connections to resources your team has already configured and secured. The app does not need a rewrite to use them.
Apps built before the new builder are now called classic apps. They keep working as they do today. The new builder sits alongside them, so you can move one app at a time, or none.
Our own engineers work this way. They write code with Claude Code on their machines and deploy it to Retool, where the controls below are already in place.
Where the controls live
The controls do not sit inside each app's code. They sit underneath every app, as one layer the platform supplies:
Hosting and deployment. Retool runs the app, with version history and source control.
Sign-in. SSO through the company's identity provider, such as Okta or Microsoft Entra ID.
Data access. Permissions set on each data connection, so one rule applies to every app that uses it.
Audit. Logs of who did what, through which resource.
Approvals. Writes to live data can wait for a named person to approve them.
Because the layer sits below the code, it applies the same way whether a person, a model, or both wrote the app. The same model holds across Retool Cloud, VPC, and on-premises deployments. Compliance and data residency arrangements do not change. For a security reviewer, that is the main point: the generated code does not have to carry the controls, because the platform does.
Why this matters more as agents arrive
An agent can only run inside a regulated company if someone can state what it reads, which endpoints it calls, and where its output lands. Without that, security blocks deployment, and it should.
The platform layer gives that answer. Each automated action runs through resources with defined permissions, is logged, and can require approval before it writes to live data. The resources, permissions, and approval steps you define set the boundary for more autonomous software. The security team sees every action, inside a boundary it already reviewed.
Five things to check before moving an app
You can move incrementally. A little preparation decides how clean it goes.
Your permission model. Import maps data connections to resources you already secured. If resource settings and permission groups are documented, import is straightforward. Access may have grown informally: admin roles handed out as a shortcut, or groups that no longer match real teams. The move will surface it. Clean it up first.
Your environments. Confirm that production and staging stay separate after the move.
The first apps. Pick two or three where custom React or agent capability adds something the current app does not do. Move those first and learn from them. Apps that already do their job can wait.
Your audit obligations. Some teams must keep a five-year trail for financial services, or export logs in a set format. Confirm each requirement is met before moving a workflow it covers.
Your SSO. The new builder uses the same centralized sign-in. Confirm the Okta or Entra ID integration is stable and documented before adding apps.
The new app builder is live for Retool Cloud customers, and ships in the Retool 4.x stable release for self-hosted deployments.
Who should build on it
Models write code fast. Shipping that code into a regulated environment still takes engineers who have worked inside enterprise permission models and passed security reviews. If your team has done that, it can start now. If not, bring in a team that has, and keep your product owner deciding what gets built. The security and compliance checklist lists what reviewers will ask. What vibe coding is, and what it takes to run the result covers the gap between generated code and a production app.
Our view
We recommend the new app builder for custom code and agents where Retool already runs, because IT's approved controls then apply from the first deploy. Start with one app where custom code adds something real, check the five items above, and let that app set the pattern for the rest. How we structure a deployment like this is in the architecture behind creative operations at enterprise scale.
