New App Builder - First Impressions

🤝 Discussion
, ,
1

I was excited to hear about the new app building experience. I have only been working with it for a day, so take my comments with a grain of salt - these are only my first impressions. I also know it was just released and in beta so curious to hear how much of these comments will become stale.

Being able to see the underlying components in code is awesome. This is what I was most excited about - the drag/drop classic interface makes building apps easy but sometimes you want custom logic. Custom components filled the gap but the experience (building outside Retool) had some friction. Really nice to be able to do this inside the Retool UI.

However, supporting only natural language querying + manual code editing actually makes the whole app building experience more frustrating. I came to Retool because I was an engineer more focused on data and backend logic and saw the platform as a way to build slick frontends without having to write a lot of Javascript. The classic builder was a really nice blend between drag/drop while still supporting custom logic with code where needed. The new experience limits you to either writing the code yourself or asking AI to do it. AI code gen tools are rarely one-shot perfection, so if you’re not comfortable editing the code yourself then you have to re-prompt the model to build to spec which will get expensive and frustrating quickly, especially for small changes like “move this component above the other one”. In addition, the UI for drag/drop was always a good way to actually understand what’s possible with a component - I can see a checkbox for “expandable rows” in a table and click it and see what that feature is - almost like living/interactive documentation. Now I don’t really know how to see documentation for the components. And there is no UI now to change a component - it has to be code or through the AI.

Editing multiple components and queries with one prompt is also awesome. If I want to say “change all my redshift queries that use X table to use Y table instead” then I can do that with a prompt and just let it go. Love that, big time saver. However, I am missing a way to see the changes being made. When I use the drag/drop editor, I know what’s changing because I did it. If there’s no way to check diffs then I am just trusting that the whatever the model is doing is correct which is probably not the correct assumption often enough for it to be able to be ignored. I can see the process of course and I can get a summary of the files that were changed but when it comes time to publish, I’m really blind as to what changes I’m really publishing.

To me, I am not really sure who this new experience is for. If I wanted to use only AI + code editing to build the app, why would I use Retool at all? Why not just develop locally using the same AI models where I can have more control over the process without paying a middle-man fee to Retool? Of course there are features on top like the database, authentication, hosting, etc. but there are plenty of platforms out there that fill this need already. This problem will become worse if tokens become more expensive (which they are likely to) and end-users will have no choice but to either 1) hand-write the code 2) move to a different platform

Theming is less flexible than the classic format and it’s disappointing that we can’t import a theme from classic. My classic app theme specifies that one font is to be used for H1 - H3 and the rest of text is another font. I don’t believe I can set that same config in the new experience. I can prompt the model to override that but it’s within the app rather than the theme, so I’d have to do this for every app every time. There is no native way to import a classic theme, I had to use an LLM to take my classic export and convert it into the format for the new version.

Modules are a missing feature. If I’m creating multiple apps and I want to use the same component in multiple places, I don’t see a way to do that now.

Classic app conversion is a big miss so far. I tried converting two things: a module I created and my core app that I maintain. In both cases, nearly all the queries were broken and required extra prompting ($$$) to fix. Some I’m not able to fix at all currently. The conversion tool took many liberties with the app layout and functionality - it’s not really useable without a ton of work. It seems to me that unless the app being converted is incredibly simple, the conversion will be disappointing and like your best path forward is to build it manually step-by-step. I think Retool should build a tool that converts deterministically rather than off-loading to an agent.

Queries seem to have more limitations. One of the issues I’m running into is that I’m suddenly getting OOM errors on certain queries. Admittedly, these query results are large but they did run in classic where now they just give an error.

Those are my current thoughts - would love to hear if there are ways to fix these issues either currently or on the roadmap.

4 Likes
Where is Retool still saving time vs AI-assisted React/Postgres apps?
App Builder eats through AI credits *way* too quickly
3

This is all great feedback, @JaredStufft! Thanks for sharing.

We're actively working on a bunch of things that will further close the feature gap, so I'm excited to hear about how your experience with the product evolves. At a fundamental level, though, building via prompt vs. drag-and-drop is a significant shift and we're trying to find the right balance.

One feature I appreciate is the ability to write prompts against specific UI components. While not perfect, it definitely helps with the kind of iterative building where LLMs have historically struggled.

image
image636Ă—356 14.4 KB

Last but not least, your feedback on classic app conversion is particularly helpful! I've definitely seen the process struggle with certain resource queries - in large part due to a lack of feature parity - but it usually handles layouts pretty well. I'd be curious to see before and afters, if you don't mind sharing.

4

Thanks for the response Darren. I’m definitely looking forward to seeing how the product evolves and hoping a lot of these concerns go away.

re: writing prompts against specific UI components - I appreciate this too but it seems a bit heavy handed for most changes. Like getting in my semi-truck to get my mail at the end of the driveway.

Re: Classic app conversion, even my layout conversion was pretty poor! I think it got maybe 60% of it correct. Given that the new app builder uses real React code underneath it, it really does feel like a utility that can be made deterministic rather than rolling the dice on an expensive LLM call. I can’t post publicly but happy to meet with you privately and screen share or whatever you suggest. Some of the differences are explained (e.g. custom components) but most of them I’m not sure how the conversion got it incorrect.

5

We'll have plenty of updates to share as time goes on! :+1:

I'll check with the team to see if they're interested in setting something up, but in the meantime you're more than welcome to join any of our scheduled Office Hours. Thanks again for jumping in and for the feedback.

6

Hi @JaredStufft, thank you for the very thoughtful feedback! I’m a product researcher on the team here at Retool. Like Darren mentioned, we have some very relevant work underway, and I’d love to chat through your feedback to make sure we’re closing the gaps you raised. I’ll follow up with you via email!

1 Like
8

Hi Jared, thanks so much for the thoughtful feedback. I’m on the product team at Retool and would love to chat more about your experience. I’ve asked Kate to include me in the follow-up call.

A few notes in the meantime:

AI code gen tools are rarely one-shot perfection, so if you’re not comfortable editing the code yourself then you have to re-prompt the model to build to spec which will get expensive and frustrating quickly, especially for small changes like “move this component above the other one”.

As Darren mentioned, you can already scope prompts to specific UI elements today. We’re also planning to ship deterministic controls for UI styling changes soon, without needing to prompt at all (e.g., modifying fonts, colors, border radii, etc.).

Layout changes are trickier to support. We made a deliberate call not to bring the exact same drag-and-drop layout editing to the new builder because, in our experience, a proprietary layout system tends to get in the way of AI doing its best work on UI. We think LLMs writing React is already pretty solid for a majority of layout changes, and it’ll only get better over time. However, I'm happy to dig into specific cases where this has felt frustrating.

I am missing a way to see the changes being made

This is very fair feedback! The Version History drawer on the right side has the full git history of changes to your app, but there’s no good way to diff between versions yet. We’re planning to add version previews soon, and eventually proper diffing (whether that’s code-based, visual, or both). Excited to hear more on what you’d like to see here.

One thing worth calling out: the AI agent in the new app builder can actually introspect the full app history, so you can also ask it for a summary of what changed.

If I wanted to use only AI + code editing to build the app, why would I use Retool at all? Why not just develop locally using the same AI models where I can have more control over the process without paying a middle-man fee to Retool? Of course there are features on top like the database, authentication, hosting, etc. but there are plenty of platforms out there that fill this need already.

For builders with an engineering background, there's a lot of optionality today and local development might genuinely be the right call. However, we keep hearing from customers that the friction shows up after the initial build: spinning up and managing infrastructure to deploy apps securely, building controls for managing data and app access, managing connectivity to databases and APIs, etc. Where we believe Retool shines, even for smaller teams, is that platform layer underneath the builder. Our MCP server now empowers builders who want to use AI coding tools to build apps from outside of Retool to still ship with that platform layer underneath (happy to dig into your specific setup on the call!).

We also think the builder itself is differentiated vs. using a general-purpose coding agent, due to the added comprehensibility and control that our abstractions provide. For example, when working with data in the new app builder, it's easy to see which resources are connected to your app, and your queries show up as named functions pulled out from the rest of the app code. This makes it tractable for a non-engineer — or even an engineer a few months after the initial build — to find the key business logic, understand it, and change it without digging through connection boilerplate. That's just one example, and the broader direction we're headed is finding the right balance between leaning into LLMs' strengths, while layering on experiences that give you better comprehension, and more deliberate control over the result.

This problem will become worse if tokens become more expensive (which they are likely to)

In our experience, we’ve seen dramatic improvements in cost vs. quality for LLM coding outputs in the past year or so, and expect this trend to continue. Would definitely encourage you to try different models within the new app builder and share feedback on how they stack up — each of our plans includes a healthy amount of AI credits that we intend to be sufficient for most building activity.

Modules are a missing feature. If I’m creating multiple apps and I want to use the same component in multiple places, I don’t see a way to do that now.

We’re actively working on adding reusability to this new app building experience and would love your feedback. First up will be introducing reusability for backend logic soon: basically a Query Library equivalent for the serverless functions in these new apps. UI reusability is in the works too, and we’re thinking about combinations of UI + logic (similar to modules in classic Retool). Would love to understand your specific patterns better on the call.

One of the issues I’m running into is that I’m suddenly getting OOM errors on certain queries

This can be avoided by using streaming queries. We’re working on enabling smarter AI agent behavior to reach for these but, in the meantime, you can try prompting the agent to use streaming for slow-running queries. Once you do this, you should see code like the first line below in your serverless functions (as opposed to the second one) —

return retoolDb.queryStreamRaw(...)

return retoolDb.query(...)

Really appreciate all of this — it's exactly the kind of feedback that's useful at this stage. Looking forward to the call!

4 Likes
9

I think your point about the missing middle ground is the most important one. The classic builder worked well because it served both non-developers and developers: you could use drag-and-drop for speed, then add custom logic only where necessary.

AI-assisted development is a great productivity boost, especially for bulk changes across components and queries, but relying entirely on prompts and code editing removes a lot of the transparency that made Retool approachable. Features like visual configuration, change diffs, component documentation, and reusable modules aren't just conveniences—they're critical for maintaining larger applications safely.

The lack of visibility into what an AI-generated change is actually modifying would also make me hesitant to publish updates without a proper review workflow. Version comparisons and deterministic migrations from classic apps seem like areas that would benefit significantly from additional investment.

I'm curious whether the long-term vision is to replace the classic builder entirely or to eventually combine the strengths of both approaches into a hybrid experience.

3 Likes
10

The classic builder isn't going anywhere anytime soon! That said, we do believe that the new experience is the future of Retool and are actively iterating on it. @timofey's post outlines some of the plans we have and the things we're working on - let us know if you have any additional questions!

16

Hi All - Long time retool user - first time giving feedback. First impressions.

Faster, but less precise on changes - could do with using real named ids for elements to make it easier to make explicit changes

Not sure how its better than just using codex or claud itself where Im able to access the code easily via a github link ?

Really need it to convert the new beta into a classic app to give the USP im looking for in retool which is a path from MVP to production / enterprise grade app building. How does it compare against Figma Make ? With the new beta if feel like i’m lured into a trap once I’ve started to build something that I can’t get out of.

Please tell me how I’m wrong and restore my faith in retool

17

Appreciate the feedback, @Barrie_Roche! On the topic of precise, targeted edits - I previously demoed some existing features that are easy to miss, but we're definitely doing more on this front.

I'm very interested to dig into your below point, though:

What functionality are you missing or do you think is lacking? At a high level, the new app builder shares our existing value prop - the ability to quickly build and deploy fullstack applications on top of your sensitive business data.

24

I wanted to post a follow-up here as I’ve been able to work with the new app builder a lot more. My comments below are much in line with my prior first impression but now with more time under the belt building with this tool.

TL;DR: the agent is very good but the surrounding environment is poor.

1) Overall I see that the new app builder allows a lot more flexibility in design and speed of development which is the greatest strength. I can build apps and designs that definitely would not have been possible before in the classic version and I can do it relatively quickly. I notice that the agent generally does a good job creating features from text. I provide screenshots of mock-ups from Claude Design and it translates those features well, and makes some decisions to simplify based on the actual application (which is good).

2) There needs to be a viable way to substantially modify applications built here that is not AI-based. If I run out of AI credits, I basically can’t work on something anymore unless I either buy more or wait for another month. With the amount of credits my plan gives me (3000/mo, which I understand is 50% “bonus” credits) I am essentially able to work for 1 - 3 days of the month. The cost has shifted from “pay for access to the value the platform brings” to “pay-per-edit for the right to modify your own tools” which is 100% the wrong metering. Am I supposed to tell my stakeholders “sorry, you have to wait a month for us to deliver this. It’s 95% done but I ran out of credits and can’t finish the work myself”? Retool can’t consider AI as the sole main editor; it can be a peer at best but it’s a requirement that humans have a viable way to do the work without any AI involved. Manual code editing helps but only a small amount since I’m not the one generating 99.9% of the code and can’t navigate it quickly; if I see e.g. a piece of text that needs change (prime manual edit candidate) then I don’t really have an easy way to tell where to even go to edit that (unless, of course, I burn some credits asking the agent where it is which then defeats the purpose).

This was one of my main points in first impression, but that was more focused on developer experience. Now this is focused on the viability of using the platform at all if work has to essentially stop because there aren’t any more credits available.

3) The MCP integration is pretty poor right now. I had hoped this would allow me to substitute my own subscription for the AI credits based on the way the feature is marketed - take advantage of the subscription I already have, use some of the AI tooling I have in my local environment, provide context from connected services that aren’t in Retool, etc. It seems that all it does is pass prompts to the AI builder, meaning it consumes my Anthropic tokens AND my AI credits and adds essentially zero value to the app-building process. Marketing this as “you can build apps from your chosen development environment” is misleading as the feature currently stands; it’s more accurate to say “you can submit prompts to the AI App Builder.”

4) We need access to the underlying git mechanics without paying additional for it. We have no way to know exactly what changes we’re pushing in a publish right now, which means we have no visibility into any potential side effects. Separately, I have no way to resolve e.g. merge conflicts that may occur and block me from publishing. I can ask the AI to do it, but that assumes I have credits available to do that. So I have to spend credits to get the agent to make a change, then I have to spend credits to have it fix a mistake it made. Starts to feel a bit like a racket. I’m currently sitting on some changes that can’t be published because of an apparent merge conflict, but I can’t resolve the merge conflict because I ran out of my credits.

3 Likes
26

Hi @JaredStufft, thanks for the feedback. I’m David, CEO @ Retool, and I’ve been following along on this thread (and many others) to get a sense for what people are thinking about using React in Retool.

Thanks for continuing to try the new app builder! I would agree that flexibility in design + speed of iteration is much improved. In shipping this new experience, we had three (internal) goals: increase the speed at which people can build apps, increase the UI quality of the apps, and reduce the number of bugs found within both Retool and Retool apps. Compared to our previous (non-React) building experience, we are seeing major leaps forward on all 3.

Now — on your other feedback.

RE #2: we are actively working on both non-LLM driven ways of editing apps, as well as investigating what it would take to get much cheaper models (e.g. Kimi, GLM) to create / edit these apps.

On the former, we are working on a point and click interface for you to be able to make modifications. (Unfortunately drag and drop will not be supported; we obviously previously supported this but in fact I would argue it was probably a net negative for most customers — it introduced a large performance penalty, led to a lot of the inflexibility in layouts, etc. IMO a LLM probably gets you to a better, faster “first app” than drag and drop ever did.)

On the latter, we think this has a lot of potential. Early testing shows that we can maybe get you 80%+ of what you would get with a frontier model (e.g. Opus, Fable) at roughly 50% - 60% less cost. We are working on how we can allow you to choose the model, as well as if we can automatically choose the best model for you. This would allow your credits to go much further. I am particularly excited about this because the intelligence required to build an app stays roughly constant… but the cost of any particular level of intelligence continues to come down. It would be awesome if building an average Retool app could cost <$1, for example, or if the average edit were ~$0.25. That’s not possible now, but I think it could be one day.

RE #3: this is our top priority internally right now for the new app builder. We shipped this MCP integration quite quickly (as an experiment), and we are seeing more uptake than we expected. The fastest way to build this was to just basically have your agent pass our agent messages. This is really not ideal (as you noted) because you then end up having approval in two places, need to have both windows open, etc. We’re now actively working on how to get this to be a lot better. The TLDR is that your agent will be the “driver”, and in fact it will be able to directly modify Retool files / apps, without having to go through our agent. We are expecting to finish coding on this new experience this week, and expect to be able to share it for beta testing in the next week or two. If you are interested in that, please let me know and I’ll see if we can get you into the beta for that.

RE #4: this I don’t have a great answer for right now. We have not prioritized a UI for seeing the literal code changes (to my knowledge). The hope is that far cheaper models + allowing your LLM to work directly with the files will solve this.

Let me know if you have any questions on the above. And thank you for the feedback! I was really happy to see that you’re willing to continue trying out this new experience, and that a lot of your feedback is directly on our roadmap already.

4 Likes
27

Hi David, thanks for the response and the visibility.

You know, my initial POV was that I really wanted to keep the drag/drop layout control but my continued exposure has made me more sympathetic. I do genuinely agree that this new experience is the right direction for building, but there is real power in being able to point your mouse at a component and manipulating or learning about it. Especially when the primary editing tool comes with a meter or has overhead that makes smaller changes too inefficient.

I think this is a great idea and glad to hear about it. Something I am really missing in my other workflows is control over model choice e.g. being able to use one model for planning and another for execution. I am also really missing the integration of particular plugins, such as GSD or superpowers, all of which help me as an engineer mitigate the risks of LLM-driven development.

Also happy to hear about this. I think one of the most valuable things you can do for the community right now is be more transparent about timelines and the roadmap. Personally I agree with the vision but candidly feel the execution so far has made me consider other options. Understanding of beta status, but some of the marketed key features feel too minimum to be MVPs especially relative to current marketing (like the MCP).

That’s a bit concerning! There are some workflows in the SDLC that should be more or less deterministic (or at least have an always-available deterministic UI) and transparent. Version control, deployment, etc. are some of those. I will re-iterate a current issue I have - I made changes to an app in the builder. I am trying to publish, but the editor tells me there’s a merge conflict. I can’t get any info on the merge conflict, I have zero ability to resolve it on my own, and I ran out of credits so I can’t have the agent resolve it for me. Even if I did, I can’t inspect what changes its making or approve it before rolling it out. That’s a big risk for enterprise or critical software… I wonder if that is not what Retool is meant for? Should I re-calibrate my expectations?

Overall - if you can, please share a roadmap and expected timeline. We have seen the value of the vision through the beta but now we want to hit the road running… we can be more patient if we know what to expect.

Thanks again David

1 Like
28

Any time soon like how soon? – If you say “anytime soon” it means that at some point it’ll go away. Could be 1 month; could be 1 year. If you have a timeline please let us know as I have a production app that would need attention, otherwise you’ll make someone lose a lot of money, and I’m probably not the only one (probs even one of the smaller ones)

29

We've publicly committed to supporting classic apps for at least 2 years after the new app-builder moves to GA. I thought that had already been shared in this thread, but it doesn't look like it - thanks for asking!

1 Like
30

I wanted to share another experience - since I ran out of credits, I just hooked up my own Anthropic API to pay for the AI edits on my own. This seemed to be even more expensive - it cost me about +/- $35.50 in API spend to make these changes:

  • Resolve a merge conflict that was blocking publishing: $8.50 using Opus 4.8
  • Make 5 blank pages + pointers on a navbar: $2.34 using Sonnet 5
  • Make one of those new blank pages the default page and then create 6 tables on the page based on a screenshot (had to take multiple prompts because the agent got the formatting wrong the first couple times): $20.58 on Sonnet 4.6
  • Take the existing tables and re-arrange them into a layout based on a screenshot - no content changes just moving stuff around: $4.00 on Sonnet 5

Pretty excessive.

Is the app builder adding a lot to the system prompt? It doesn’t seem like that’s getting cached if so. I’m also not sure what the default “effort” is (zero visibility there) which could explain part of it.

31

That's interesting data, @JaredStufft. :thinking: I'll check to see if there are any internal benchmarks that I can use as a point of comparison. I've seen that we estimate a cost of $10-25 when converting apps, for example. Regardless, token efficiency is definitely front of mind; we have several engineers working on potential improvements in this area.

Caching is one strategy that definitely already utilize, but I can also check to see if your hit rate is low for some reason. I will say that screenshots, as helpful as they can be, do consume a fair number of tokens depending on their size. Do you see any breakdown between prompt and completion tokens?

Last but not least, it looks like we use the default effort in most cases. For the majority of Anthropic models, this is high. I can certainly look into exposing a way to tune that!

32

Thanks Darren. I saw that note about the app conversion, which I assume is a pretty intensive operation, and was comparing to that too. I don’t know if that’s apples-to-apples but I was just kind of surprised how quickly it drained my account. The high effort is definitely part of it (I rarely use high). I’m also hoping part of it is skill error such as passing screenshots. I’ll try to pass text specs from now on.

Overall I spent $55.90 which is about 85.9M (!!) input tokens and 121k out. That’s a 710:1 ratio. Something is amiss.

33

Makes sense. We do provide deterministic ways of doing some of the above, although not all. I agree that having some visibility / non-LLM-driven control interfaces for this would be good.

I’m not sure about the relative roadmap prioritization of this, @Tanner_Pierce, do you know?

On these costs — I think this will soon get better once we have our native CLI / MCP out. @Prajya_Sharma, I believe we are starting a beta for it this week. Can we please get @JaredStufft in on the beta so he can try it out?

34

Hey @JaredStufft! Tanner here from the product team :waving_hand:
Agree that not being able to self resolve or audit a merge conflict is a bit of an anti-pattern… Will raise this with the team and see if there’s a better UX we can implement here.

Can you say more about some of the things you hope to accomplish deterministically beyond resolving merge conflicts. You mention “version control, deployment, etc.”, but would love to better understand your painpoint.