The new Retool app builder is here!

The new Retool app building experience is finally here! We've rebuilt the app builder from the ground up, and it changes what "building in Retool" means.

How it works: Describe what you want, and the builder generates a full React app, connected to your production data, with auth, permissions, and audit logging already in place. :magic_wand:


There are now 3 ways to build:

Build from a prompt. The new builder is AI-native. Describe the app in the Chat tab, get a working version wired up to your data, and refine from there in natural language or directly in the Code tab. App builder docs

Build from your coding agent. The Retool MCP server lets you generate and deploy Retool apps directly from Claude Code, Cursor, or any MCP-compatible tool. If that's where you already work, you don't have to leave.

Import apps you've already built. Got a React app sitting in Lovable, Replit, or a GitHub repo that never quite made it to production? Import it as a ZIP or via GitHub, connect it to your data, and ship it with governance attached.

Note: Apps built in the drag-and-drop IDE are now called classic apps, and they keep working exactly as they do today. Every plan includes bonus AI credits and free hosting through July 1.

Where to start

We can’t wait to see what this community ships! Share in :handshake: Community Show & Tell category, tag it with new-app-builder, and tag us in your social posts :heart_hands:

7 Likes

With the release of the new App Builder - im curious what the future for ā€˜classic’ apps looks like? Is retool going to still be putting resources into that solution?

I really hope so - we personally have alot of production tools build on classic and i am not going to convert them any time soon to sudo ā€˜vibe coded’ react apps. I will say the new builder is impressive, but makign that jump is jus tnot in the cards currently.

Just curious what the landscape looks like in the future looks like for classic with regards to updates/fixes/optimization.

Thanks!

3 Likes

I gotta say – I hate it.

I made a simple UI in 5 minutes, but it feels I have ZERO control over anything, the UI looks like whatever the machine decided, I couldn’t edit the table names that it was suggesting, it populated with just demo data that I didn’t want, and it made a lot of decisions that weren’t called for. All for a simple time tracker with 2 fields and 2 tables.

Cool stuff to make junk prototypes to test proof something or look cool as a 19 year old in front of your new boss. But I have ZERO trust that this tool will do good things.

It makes random and arbitrary decisions on schema, relationships, table names, column names and everything is just created for you. Now I need to revise what it did so I can build on top of it.

It created some code that again I need to revise.

So then this creates MORE work, in the form of debugging and reviewing code that could be great, but can also leave massive gaping holes in security, data management and so many other areas.

I’d strongly ask the Retool team NOT to commit AI suicide with tools like this. It’s sad because it’s great, but it’s terrible at the same time.

Call me a dinosaur, but I prefer to build my own schemas and make sure that relationships are solid, scalable and I know what’s happening rather than letting some advanced algorithm to make random decisions on my behalf and actually altering stuff in the database directly. Again, might be good for a dev environment to create quick sketches, but you won’t see me deploying any of these apps in a prod env.

Please please please, keep your senses and don’t become AI-tards, as harsh as it can sound, it comes from a place where we value what you have. That’s why we came here and some have stayed here. <3

7 Likes

Totally agree with you. It seems like the Retool team is going in the wrong direction with this. They think users only require prompting assistance but classic apps is actually better because you can customize everything to your liking with much more granular control. if in the new app version I prompt to create a simple page and i want to change the color of a button, i don't need to type in a long prompt again just to change that single value. This is a really terrible idea in my opinion. They think building with AI only helps you build something faster but its actually the opposite way around.

They should focus more on enhancing and improving the existing "classic apps" IDE with more flexibility options without this stupid marketing idea that is already bound to fail. Converting a classic app into the new "prompt only" is a recipe for disaster. You might be able to build quick SPAs but nothing close to enterprise level.

In my classic app, 90% of my app's interface is built with only the HTML component because Retool lacks many customization features in their native components. And now they're even going more downhill. Retool should rethink what users truly need.

2 Likes

Thanks for raising this! Classic Retool will continue to be supported for at least two years after the new experience reaches GA, so you'll have plenty of time to plan any migration. We do expect customers to move to the new experience over time, but there's no immediate cutoff or action you need to take today. Your production tools on classic aren't going anywhere. We’re also still committed to fixing blocking issues and incidents for folks using the classic app builder throughout that period.

If there’s anything else holding you back from converting your apps today, we’d be open to the feedback!

1 Like

Really appreciate you taking the time to write this out. A bit of context on the direction: we've had substantial pull from customers toward prompt-first building, and we think there are real advantages to it. Retool's mission has always been to help people build great software, so as the way people build evolves, it's important the platform evolves to support that. But, that's only worth doing if these tools actually make builders faster without setting them up for rework down the line, and if what's generated is trustable and inspectable.

It sounds like you’re running into a few things we’re actively working on. The agent today can be over-eager and can default to building before it fully understands what you want. We're investing in intent clarification, planning steps, and tuning it to work more collaboratively rather than racing to a result.

A couple of things that can help in the meantime: if you want to reference specific data, it helps to seed your data beforehand and @ tag any existing resources that you want it to use. But, it definitely should be asking for your approval before creating tables against anything. If it created tables without checking, that might be a bug or a gap we can help tackle.

Where would you most want more control in the building experience? I'd be happy to get on a call and dig into the specifics if you’re open to the discussion.

Appreciate you laying this out. Striking that balance between AI-driven changes and manual changes is something we’re hoping to learn even more about through the beta period. We’re already actively working on a few more experiences that give you more control, like point-and-click visual editing for styling changes and manual control over managing files in your app code.

The broader bet is that we’re searching for the right abstractions that allow LLMs to do their best work, while also giving builders better comprehension and more deliberate control over the result. Working with data is one example: we pull your queries out as named functions so they're visible and editable, rather than buried in the rest of the app code.

I am curious about your HTML component use case though, because I’d actually expect the new app builder to be an improvement for the types of UI’s you’re building. It sounds like our native components weren't flexible enough to give you a great out-of-the-box solution, so you ended up repurposing something for a use case it wasn't really meant for. Prompting against the new React-based app builder (or editing the code directly) can be more directly accommodating of those possibilities, without asking you to come up with clever workarounds within our list of components). I'd love to know whether that lines up with your experience, or where it doesn't.

2 Years? That makes it sound like i need to start migrating my 150 users to a new solution post haste. Are you saying the myriad of current bugs/linting errors/runtime editor quirks and errors are just not slated to get resolved? There are so many great things about retool in its current state - and building in better AI functions absolutely should be a part of its future - but the core of retool also still could improve so much!

Your response here does not give me any warm fuzzy feelings at all - and im quite dissapointed. We quite literally just started developing an full blown ERP managment tool that sits on top of Netsuite several months ago and the project is going so well…and to be fair, i tried to port that app into the new builder. And it simply…fails. Will not convert, and i will say its quite well organized/consistent etc.

Hoping i misunderstood your response and timeline somehow…I will hate losing the hundreds of hours of dev work already done on this project…

-MD

1 Like

Everything was flowing fine with the new app builder until it was time to create a public link. Despite having the Enterprise level, it has not been enabled for me in Advance Settings. Has anyone else come across this issue? The matter is pretty upsetting to me. Why would the other app builder allow it and this one would not?

Hey @msd5079 I don’t think you’ve misunderstood, but I’ll qualify my earlier comments and hopefully allay some of your concerns: concretely, we’re committing to supporting classic apps for at least 2 years from the time the new app builder goes to GA (note: the new app builder is currently a beta product and will remain in that state for some time).

During that time, we’ll invest in making the new app builder more fully-featured, including improving our classic apps conversion experience, such that you’ll be able to successfully re-create — and, in some cases, perhaps even improve — existing apps.

If you’re open to it, I’d love to jump on a call to better understand where things went wrong with your app conversion, and what it would take for you to gain confidence that the new app builder can support your future use cases (I’ve reached out by email). Really appreciate your input!

1 Like

Hi there, I'm on the product team at Retool. Sorry for the friction here, I can see why hitting that wall is frustrating, especially when the classic app builder supports it.

Public links aren't supported yet for apps built in the new app builder. It's a capability we haven't brought over, not a problem with your account or plan. It's actively on our radar, and input like yours helps us prioritize. Would you mind sharing a bit about your public app use case? We're collecting that here so we can design the right solution.

2 Likes

Hi I am wondering if there is a positioning change with ReTool. Feels like with free tier going away and no moving to agent based development you position in the market is changing. Especially if the old app builder will be deprecated in a few years.

this is a must have for us to convert to the new app builder

1 Like

The Free plan isn't going anywhere! The market as a whole is definitely shifting and we're leaning into AI-driven capabilities, but we feel strongly about offering everyone an accessible way to get hands-on with the Retool platform.

Noted, @Candry! We'll keep you updated. To @timofey's point, do you mind sharing a bit about what you're building and how it relies upon public access? We want to understand everybody's needs and do this right.

Sorry, self hosted free plan.

1 Like

Retool is great for internal app building which ticks all checkboxes without any complains. However, not all apps are intended to be internal and many are public. And when it comes to public, UI/UX becomes paramount. We cannot simply accept building a random UI with the standard Retool components and frames which are limited in styling as well as functionalities. So the only the way to overcome this is to use HTML which helps solve two issues. The first is opening the flexibility to build almost anything pixel-perfect, and second it aids in making the app much faster by eliminating retool components which include many wrappers in the DOM. When I started replacing almost all components to HTML, I noticed how fast the app started to load compared to before. Less components and queries = Faster initial app load. It would have not been possible to create the front and backend account portal without the use of the HTML component. The Retool native components simply lacked many stuff. To be fair though, the only places where I used them is for forms where text input and selections are required. But knowing that Retool was initially build for internal tools, I am satisfied with what I have and I'm not complaining at all in this part.

However, the issue with the new app experience is that the user is solely reliant on prompting the AI model which can easily consume credits. Like a few days ago, I wanted to try what it can do. I typed in a short prompt to build an excel-like spreadsheet and after some 10 minutes, it created a good overall layout but then the prompt box was locked and I could not continue any further. What should happen then? How am I supposed to keep editing queries, variables, transformers when almost the entire interface of the classic apps is all gone? Do you expect users to go to the edit tab and manually search and edit through lines and lines of codes? That wouldn't making things "easier" but much much "harder" to build.

If that's how it goes, then I have no reason whatsoever to continue using Retool and I'd be better off migrating the app locally and hosting it on my own server with no caps, no limits and absolute peace of mind. But since the new app is still in its very early stages, I don't want to quickly criticize it. I'll wait and see what comes out of this but that is not news I would be hyped for. Good luck anyways.

Sure, we use Retool to build applications on top of various databases and Api resources. We manage permissions internally in our ERP database which is the source of truth for all 3rd party platforms. Since Retool does not offer Microsoft oath in the business plan we have built our own 2 factor auth workflows which is great for keeping permissions inside our ERP and limiting what users have access to internally in retool. We share public apps with outside vendors and team members that might only need one form to collect data which a full retool user license does not make sense.

Basically, we do not need another platform to manage users and permissions when our source of truth does this for us.