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.

1 Like
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.