The new Retool app builder is here!

[Candry]

@Retooler

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.

I agree with this in that I think having the AI build the bones is great and fast however when trying to edit there should be a better way of linking the component to the actual code location. IE. if you double click the component, it should open the edit location of the Ui and or ask where you want to edit the actual Ui code or the hooks that drive the component. This would make small edits like color, type font easier to manage without consuming credits.

I agree in that they way the AI world is moving it is easier than ever to self-host and manage the backend code, which is especially what retool is doing. I feel like this is basically a hosted VSCode UI rebranded as retool designed for vibe coders that are not familiar with setting up VSCode and hosting resources.

I think there is value in not having to stand up servers and managing the file structure however heavy use dev’s are not going to spend $$$ on AI credits. That’s not realistic.

I love the AI Assist in the classic retool UI. I think this is best of both worlds. While it’s not perfect it can build quick mockups and pages while also allowing full control of the UI elements and code form a single screen. I would love to be able to merge the 2 experiences.

[PadenM]

I actually think the direction Retool is going with the new App Builder is pretty key. I’m glad they’re moving more toward standard React files and letting you see what’s actually going on under the hood. There’s just a lot more customization you can do that way, and having access to the real files is super helpful.

I can definitely see how this could slow people down if they’ve never used done stuff by hand before. But if you’ve done normal code development, I think this is a big plus.

I’ve barely played with the new stuff so far, but I like the direction. I originally came to Retool because it made building internal apps way faster. But over the last month or so, I actually started moving away from Retool a bit because with tools like Codex and Claude, I felt like I could build what I wanted even faster outside of Retool.

So honestly, I think Retool would be silly not to push this direction. AI-assisted development is changing how fast people can build, and this seems like the right move if Retool wants to stay useful for people who want speed but still want more control.

So good job Retool.

[David_Bolen]

Totally agree with both of these posts. I was initially very excited about Retool headed in this direction and the exposure of the native code. Thinking it would be like Base44 and give me more control. But quickly ran into the same limitations both of the previous posts point out. Having done extensive workin in both Base44 and Retool, i was hoping retool would provide the power of the structured ui to speed development around a simplified framework, but the flexibility for the 10-20% of the edge cases that require resorting to hand or workarounds that end up taking 80% of your time. I’m also finding platforms like Base44 / Claude, given the correct context and boundaries, you can steer them into well architected objects - but you have to be very vigilant to maintaining that structure. With retool’s ai generated code it feels like it’s a few generations behind even Base44 and Claude.

Before this introduction i was seriously considering moving my entire customer service system out of retool into Base44 with retool only serving as the workflow endpoints for the backend. Because productivity was just so much higher.

However, this does give me pause and hope. This is just the initial release. I’m hopeful / optimistic the retool team will see the benefits and develop clever ways to fuse the classic retool editing with ai generated / raw react editing.

That would be very powerful. 80% of code up front, experts for the remaining 20%, classic retool for Maintenance (tweaks and enhancements - all of the AI driven tools suck at this part which is the majority of an apps lifecycle. This is where classic retool - architected properly - excels).

[Darren]

Thanks all for the discourse! It's super valuable for us to get a diverse set of feedback in these early days. One of the common asks I've seen both here and elsewhere is for a way to still do targeted, granular editing. While there's more work being done, I thought I'd share a quick demo of two features that are currently flying under the radar:

[LBCooper]

@Darren and @timofey
My use case is that I am in a five-week Challenge to create a product and earn $1,000 in that time. I have put the equivalent of $16K in labor hours into development using the classic Retool builder. It was very unstable toward the final process. This after actually getting a downloadable result.

When I took my code over to the new app builder, it was faster and easier to build, but then it became “hostage” to the fine print at Retool–meaning you can build it, but you can’t use it until we release that part. So the 3Q is approaching, and my lead magnets and potential sellable tools are not ready. I didn’t realize that Retool was set up as an internal app platform for larger companies’ internal use when I signed up as a start-up business. I appreciate the offer. Your CEO clearly meant well, but the fine print should have been more evident.

[gkahen]

@timofey I’m very disappointed to learn that Retool’s app builder is being deprecated. The app builder (and the Retool cloud infrastructure that backs it) has been an incredible value for our team. One of the reasons it has been so valuable is because of how flexible it is - it’s low-code when you need to move quickly, and highly customizable when there’s specific functionality Retool cannot provide out-of-the-box.

The new editor is clearly intended to be low-code, but lacks the features of the “classic” app builder that allow you to shape the app’s UI and function in important, specific ways. It is impressive what the new builder is able to put together, but the absence of all the Retool features in the classic app builder really makes development feel like building a ship in a bottle; where the bottleneck is the AI prompt.

If we lose the ability to maintain existing apps or build new apps in Retool without an AI prompt, I don’t see how we will be able to extract value out of this product going forward. I urge you to please reconsider sunsetting the “classic” app builder.

[paul.narup]

@timofey @Darren Will there be any changes to the deployment process for those not on the enterprise plan? We are currently maintaining 2 versions of the same app (dev & prod) manually because of lack of git access. Will git be available outside of the enterprise plan?

With this change to vibe coding, if git is not unlocked for lower tiers, I will likely not be able to recommend Retool to clients in the future as I can have tools self host and spin up a react app with the proper SDLC outside of Retool.

[Darren]

As far as I know, external SCM integrations will continue to only be available on the Enterprise plan. I'll let you know if I hear differently.

That said, the new app builder is built to be fully git-native. In the current paradigm there is a one-to-one relationship between chat threads and branches, but we're reevaluating this and looking for the right UX.

[Becca_Campbell]

Adding my 2 cents here, too, so I know when public links will be available on the new app builder. Love the new app builder, but need the public links Use case is simple: building form inputs that can update retool databases, which other retool agents can then work off of.

[Darren]

Welcome to the community, @Becca_Campbell! And thanks for sharing.

You can follow along here for updates.

[FCCS-MH]

I’ll admit, I was not a fan of the new builder at first. But once I was able to see how flexible you can be with prompting, and how quickly you can get something usable up and running, I can’t lie, I’m sold. Just hope we get public-facing URL support soon!

[Darren]

Glad to hear it, @FCCS-MH! Thanks for sharing - I'll be sure to keep you and everybody else here in the loop.

[the_irav]

I think You’re facing a spin-off moment (Retool). The new Retool is a whole new thing, very different from what got me here.

As @Retooler said, it’s alright to do a quick single-purpose app or help break the blank canvas freeze and get momentum. I started building a small work timer tracker app and my experience has been okay…ish. Building the environment and runtime and all takes a bit of time and executing some prompts can take also a fair bit of time but overall is okay. Haven’t ran into limits yet as I’m treating this precisely as a small disposable experiment so prompts and changes are short and incremental (as you do), and while it works, it still doesn’t feel right nor worthy to integrate into some other ideas that I’ve been brewing using Claude.

But it’s insane how it feels so removed from my workflow. I can check the code but feels like reading something so alien to my natural logic in creating things, in spite of it being very short snippets and rather simple scripts, that I feel completely detached and very insecure of what I can edit without breaking things. And if I did break something, then my ability to know where, how and why is also reduced. The knowledge I develop by creating something myself it’s completely gone with the new tool, not improved. There’s a difference between being Jackson Pollock and just throwing random paint on a canvas at a fast rate.

It becomes a very opaque box, not a black box, not an impossible thing, but far from a code panopticon (which might sound cool, but also probably not great either… balance is key)

I also made the kind of rookie mistake of asking some edits which destroyed a few things that I liked, luckily the DB didn’t get nuked as I thought it had. – Don’t care about this mockup anyways but reinforces the idea of play but never deploy, which begets the question of what’s the point of building to never publish/deploy because of the testing and code examination needed is large.

I tried to dive into the code again and I have to examine everything line by line and this thing wrote already more lines I’d like to read. Plus while is cool, the verbosity on some of the comments sometimes is unnecessary. Again, feels weird.

So again, I think it’s a full fork / spin-off. There’s a new product, that is not Retool. If this is the future of Retool, I think I’m out.

Another option is to properly integrate the AI assistance into the existing Retool.

Getting help for boilerplate code from an AI is valuable. Having to “hand in the keys” and let the whole thing start doing wheelies and spinning your car around, plus change the paint, new rims and hang a pine thingy, shop your groceries, bathe your cat your dog and your wife, when the instruction was simply “Park my car”, is not.

[msd5079]

@the_irav I 100% agree with your sentiment above. If they would fork this off into a secondary product - then sure, let it be whatever it is they are after. But, dont just get rid of what brought us all to retool in the first place, which is to bridge the gap between drag and drop, and full blown custom applications. I have tried to create a few ‘new apps’ – not a single one has gotten to where i wanted it for many reasons. Really hoping Retool pivots here…like you said, improve the ‘assist’ to work better with the native app builder and tools, there is value in that.

[mascaritas]

I feel like I must be missing something here, so I'm genuinely asking: how is the new app builder supposed to work in practice without drag-and-drop?

Drag-and-drop visual editing has always been Retool's killer feature — it's the whole reason I chose Retool over alternatives like Appsmith, Tooljet, or just building raw React apps. Being able to quickly lay out a table here, a button there, move things around visually, and connect them to real data in minutes — that's the productivity win.

Reading through this thread and the docs, it sounds like the new builder is AI-prompt-only plus raw code editing. No drag-and-drop, no visual component tree, no property panel where I can tweak things without a prompt.

Am I misunderstanding? Is there a drag-and-drop mode I haven't found? Or is the vision really that everything goes through the AI prompt, even simple layout tweaks like "move this container 10px to the left"? That would mean burning AI credits for every minor adjustment, and honestly feels like a step backward in developer experience.

I really want to understand the workflow from someone who's actually shipping production apps with the new builder. How do you handle rapid iteration on layout without visual tools?

[FCCS-MH]

@mascaritas

I really want to understand the workflow from someone who's actually shipping production apps with the new builder. How do you handle rapid iteration on layout without visual tools?

The new builder is so much better at contextualizing your requests that building things with a hybrid approach (drag and drop > asking prompt for help > doing some manual coding > repeat) is just much slower and clunkier. The new builder builds things really effectively without much handholding, and the apps look much nicer to boot.

I have 2 production apps I am using the new builder for now, one I converted from a classic app, the other I built out in the new builder… and a number of pre-prod apps that we’ll likely try to deploy once the new builder is able to handle public-facing URLs.

I was initially against the new builder because, by design, it removes/hides behind the curtain almost all of the hands-on controls we got used to in the classic builder. The simple reason for this is that the new builder simply doesn’t need those old constraints, and works faster building stuff in its native react format. However, now I can see that it’s MUCH faster, and nicer looking, and the builder is more competent than the classic assist ever was.

I recommend just dropping in and trying to build things without worrying much about the backend. You can still direct it if you know what you need it do to and can use the old terminology for things (use this table, target this resource, build a modal, etc…).

[Darren]

The new app builder is undeniably a significant departure from the classic experience and I think it's only natural to initially feel a bit uncomfortable with the change! I'm glad to hear that you've given it a shot and can appreciate some of the benefits it brings, @FCCS-MH!

To answer your question, @mascaritas, there are a few different ways we're thinking about the future of visual editing. Timofey shared some additional context above:

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.

Notably, drag-and-drop isn't currently part of that roadmap. To echo @FCCS-MH, though, I've found the new builder to naturally produce apps with a significantly better UX. I'd be curious to see how much iteration you actually end up needing to do in a real build.

[mascaritas]

I get it, or I see the idea. However, I do not currently have a plan on how to convert one or several of my daily-use apps into the new format. They consist of at least three different API queries, which all have particular traits.

I was wondering: how could I carry over the main queries and their settings without dragging all stuff I have piled up in UX over time along into the new format?

I have workflows such as:

- Rendering HTML blocks

- Sending them to a PDF conversion endpoint

- Saving that PDF as a file

- Reading it in

- Converting it

- Mailing it

Will it be able to carry that over without breaking the whole thing? I know I could just try, but if I convert it, I also want to clean it up and only carry over what makes sense.

[Darren]

Good question, @mascaritas. Right now, app conversion is an all-or-nothing process in the sense that you can't opt to specifically convert queries, for example. Also, certain resource types - mostly niche DB connectors at this point - still aren't supported in the new builder, which can complicate things.

In general, though, I think my recommendation is to duplicate an existing app, remove all the "bloat", and then try converting the stripped-down version.