Questions about new app builder beta

[benjaminfortunato]

Thanks for the invite. I’m interested in joining the beta, but I’m trying to get past the marketing layer and understand where the new Retool app builder actually fits architecturally.

Right now we’re deciding between three broad approaches for our internal admin/backend tooling:

1. Airtable as a fast no-code operational UI

2. Retool as an internal app builder over our existing backend/database

3. A more traditional custom React/Postgres app using Cursor, AI agents, Builder.io, etc.

Each path has real tradeoffs, and I’m trying to understand whether the new Retool app builder changes the equation enough to justify revisiting Retool.

Current Airtable experience

We started building a POC in Airtable to run parts of our admin backend. The biggest advantage is speed.

In Airtable, we can create tables, views, forms, gallery views, list views, filters, single-select and multi-select tags, and basic CRUD workflows very quickly. We do not need to build basic CRUD endpoints just to let internal users interact with data. Filtering, searching, browsing, and editing are all available out of the box.

That part is extremely powerful.

The downside is that Airtable starts to break down when the app becomes more serious:

• Base record limits become a major constraint.

• Automation limits become a major constraint.

• API-driven actions can be slow.

• Splitting an app across multiple bases creates additional engineering complexity.

• Synced tables introduce their own limitations.

• There is limited support for real frontend customization.

• The “database is the view,” which creates issues when trying to build more complex views across multiple related tables.

• Multi-user / permissioned access patterns are not first-class in the way a real app would need them to be.

• Version control and development workflows are weak compared to a normal app stack.

We’ve created workarounds where users can flag records, select multiple records, trigger actions, and view records based on user preferences or project access. But these are workarounds, not first-class application patterns.

So Airtable lets us move fast, but the record limits, automation limits, and lack of proper app architecture become painful.

Current custom app / Postgres experience

The other option is to build a proper app ourselves.

We already have our application logic moving into a proper backend using DDD / hexagonal architecture. The domain logic lives in the backend where it belongs. That part is not something I want scattered across no-code workflows.

The upside of a custom app is obvious:

• Full control over data modeling

• Full control over permissions

• Full control over frontend UX

• Proper CI/CD

• Proper version control

• Proper API boundaries

• Better long-term maintainability

• No artificial record limits from a no-code tool

The downside is that everything has to be built.

Need a PDF viewer? Build or integrate one.

Need a good data table? Build it with TanStack Table, Radix/shadcn, etc.

Need filtering UI? Build it.

Need a gallery view? Build it.

Need nested lists, bulk actions, saved views, user-specific preferences, role-based views, import tools, admin workflows? Build all of it.

AI agents and tools like Cursor have accelerated this a lot, but there is still a lot of setup and infrastructure work. Even getting tools like Builder.io properly integrated into a real workflow takes time. CI/CD, auth, environment management, component structure, deployment, permissions, and design system decisions all need to be thought through.

So the custom app path gives us the architecture we want, but it has a lot of upfront build cost.

Where is Retool supposed to fit?

This is the part I’m trying to understand.

Retool has historically been marketed as a fast way to build internal CRUD tools. But that was not really my experience with the previous Retool builder.

We were using Supabase/Postgres as the database. Maybe that affected the experience, but in practice we had to build a lot of CRUD behavior manually:

• Create read queries

• Create insert/update/delete queries

• Wire those queries into UI events

• Handle filtering and pagination

• Work around component state issues

• Build custom UI for anything outside the default table pattern

Tables worked reasonably well for basic use cases, but once we needed nested tables, gallery/card views, tags, filtered views, or more complex relational interactions, we ran into a lot of friction.

For example, if we wanted a filterable gallery view, there was no clean out-of-the-box pattern. We had to build custom filtering logic and custom UI. If we wanted to filter on tags, we had to translate tag structures into something the Retool UI could work with. If we wanted server-side filtering, we needed to create API endpoints that supported all the filter combinations we wanted the UI to expose.

At that point, the question became: are we actually saving time, or are we just building a custom app inside a more constrained framework?

The drag-and-drop UI also caused friction. It was hard to precisely control layout, styles, and component behavior. The AI agent did not work well enough to materially change that. We ended up spending a lot of time fighting the builder rather than building the product.

What I’m trying to understand about the new app builder

It looks like the new app builder may be a significant architectural shift, especially with the Cursor MCP server and the ability to work more directly with React code.

That sounds promising, but I’m trying to understand what the actual workflow is.

A few specific questions:

1. Are new Retool apps now essentially React apps inside the Retool platform?

2. Where does the Retool framework start and stop?

3. What parts of the app are standard React/TypeScript, and what parts are Retool-specific?

4. Can we work effectively from Cursor or Claude through the MCP server, or do we still need to spend most of our time inside the Retool UI?

5. Where does the code live, and how is it versioned?

6. Can we review, branch, and manage the app like a normal codebase?

7. What UI components are available out of the box in the new builder?

8. Are tables, filters, forms, galleries, nested lists, saved views, bulk actions, and role-specific views first-class patterns?

9. If we use our own Postgres database or our own backend APIs, do we still need to manually build all basic CRUD operations?

10. Does Retool provide any automatic CRUD layer if the data is in Retool Database but not if the data is in Supabase/Postgres?

11. What are the practical limits around Retool Database, API calls, workflows, app usage, and data volume?

12. Is the intended architecture that business logic lives in Retool functions/workflows, or can Retool cleanly act as a thin UI layer over an existing backend?

For us, the ideal architecture would be:

• Domain logic stays in our backend.

• Retool is a fast internal UI layer.

• Retool can quickly create performant list/table/gallery/detail views.

• Retool can handle basic internal CRUD without tons of repetitive wiring.

• Complex actions call our backend APIs.

• The app can be edited with AI agents from Cursor/Claude.

• Code is reviewable and version-controlled.

• We avoid hitting hidden platform limits later.

What I do not want is:

• Domain logic scattered across Retool workflows.

• A bunch of fragile one-off frontend queries.

• A builder that is fast for a toy table but slow for real relational workflows.

• A system where every non-standard UI pattern requires fighting the framework.

• A platform that looks fast upfront but creates downstream architecture problems.

The core question

I’m trying to understand whether the new Retool app builder is closer to:

Airtable, but more powerful and app-like

or

Custom React, but faster because Retool provides auth, resources, deployment, components, and AI scaffolding

or

A constrained proprietary app framework where we still have to build most of the hard parts manually

Those are very different products.

If the new Retool app builder lets us use agents to quickly generate real React-based internal tools over our existing backend, while Retool handles deployment, permissions, resources, and common internal app patterns, that could be extremely valuable.

But if we still need to manually wire every CRUD operation, build every non-table UI pattern ourselves, and fight the framework whenever we leave the happy path, then it may be better for us to invest the same time into a traditional custom app stack.

I’d be very interested in beta access, office hours, architectural guidance, or examples of more complex real-world apps built with the new system.

In particular, I’d love to see examples involving:

• Postgres or Supabase-backed apps

• Many-to-many tagging

• Nested relational views

• Gallery/card views with filters

• Bulk actions

• Server-side filtering/search/pagination

• User-specific saved views or preferences

• Role/project-based data access

• A thin Retool UI over an existing backend API

• Cursor/Claude-driven development through MCP

That would make it much easier to evaluate whether Retool fits our architecture or whether we should keep moving toward a custom React/Postgres workflow.

[Darren]

UPDATE: Actually, I jumped the gun. I'm going to close this topic as a duplicate of the one you started over here!

---

Great questions, @benjaminfortunato. I'm going to break this post out into a new topic, as I imagine quite a few folks would would be interested in the answers!