Everything you need to know to build your first app in Retool

Building an internal tool is exactly the headache engineering teams try to avoid. It means standing up a front end, wiring it to your data, and sorting out permissions and hosting. That's a lot of engineering for an app only your own team will use, which is why so many internal tools stay stuck as spreadsheets.

Retool's app builder does that work through an agent. Instead of building the components yourself, you describe the app you want in plain language, the agent generates working React code connected to your data, and you refine the result by further prompting or by editing the code directly.

In this guide, we’re going to walk through the full flow of using Retool’s app builder to build a simple app, from connecting a data source to publishing an app your team can use. All you need is a simple prompt, an initial data source, and the ability to think through what your users should be able to do.

How do Retool apps work?

If you've built in Retool before, the first thing to know is that the new builder works on a different model. You don't assemble an app from parts on a canvas. You tell an agent what to build, and it writes the app as real source code. A few concepts cover most of what's going on:

You build by prompting. The Chat tab is the primary way to build. Describe what you want in natural language, and the agent generates and edits React source code on your behalf. You can open the Code tab at any time to review or modify the code by hand.
Resources connect your data. A resource is a saved connection to a database, REST API, or other data source. When you prompt, @-tag a resource by name to tell the agent which connection to use. If you don't specify one, the agent inspects the schemas of your available resources and suggests one.
Functions handle the data layer. Apps talk to resources through serverless, strongly typed TypeScript functions rather than a GUI query editor. Functions can be multi-step, and you can view and test them in the Data tab and the Function playground.
Layout is responsive by default. There's no fixed grid and no drag-and-drop canvas. The agent places and arranges components, and you adjust the layout by prompting or by editing the code.
Apps can have multiple pages. React Router handles navigation between pages.

If you are familiar with Retool, then it still looks the same; you are just using chat to build instead of drag-and-drop:

Two things to know before we get started:

1.
An org admin must configure at least one AI resource before anyone in the org can build with the agent. AI usage is metered at the org level using credits. If prompting doesn't work on your first attempt, this is the most likely reason. The configuration guide covers setup.
2.
Not everything from classic apps carries over yet. New apps don't support modules, custom component libraries built for classic apps, or private npm packages. They're mobile-responsive, but native mobile apps still use ToolScript. For a fuller picture of the architecture, see how it works.

Step 1: Connect your data source

Retool works best when it has something to build against. By giving Retool data, you allow it to understand the structure of what you’re building, and it can generate functions and components that match your actual schema, rather than guessing at table and field names.

A resource is a saved connection to a data source. Postgres, MySQL, Snowflake, a REST API, and Retool's own hosted database all work the same way once connected. You can create a resource ahead of time from the Resources page, or pick an existing one while you prompt by @-tagging it by name, which tells the agent exactly which connection to use.

If you don't have a database to point at yet, Retool DB is the quickest option. It's a hosted database built into Retool, and there are two ways to set up a table:

Describe the table in a prompt, and the agent creates it for you.
Build it by hand in the spreadsheet-style interface, adding columns and rows directly.

How Retool DB works

Retool DB combines spreadsheet ease with database power. Click into cells to edit data directly, but get real database features: typed columns, primary keys, foreign keys, unique constraints, and environment separation (development, staging, production).

What’s the difference between Retool DB and a spreadsheet?

Unlike spreadsheets, Retool DB enforces data types, prevents duplicates with unique constraints, maintains relationships with foreign keys, and provides schema migration tools. You get spreadsheet convenience with database reliability.

Use Retool DB for app-specific data, prototypes, and operational tables. Mix it with external databases—use Retool DB for application state while connecting to your existing PostgreSQL, MySQL, or MongoDB for source-of-truth data.

Here, we have an inventory table in a Retool database that will underpin our app. We just @-tag it in the initial prompt, and the agent will use this data to build out our app:

With either an internal Retool resource or external data, tables come with properly typed columns and support for foreign keys between tables. You can import existing data from a CSV, or seed tables with sample data while you're still working out what the app should do.

Step 2: Build the app by prompting

From the Apps landing page, click Create > App and write your first prompt. The first prompt sets up everything the agent does next, so it pays to be specific:

@-tag the resource so the agent connects to the right data.
Name the components you want, like a table, a filter bar, or a detail panel.
Describe what users should be able to do in the app.

Vague prompts still work, but they cost you more rounds of iteration. The prompting best practices doc goes into more detail on what the agent responds well to. Here is the short but precise prompt we are using:

Build an inventory management tool using the inventory_data database in @retool_db. Show a table of all inventory items with product name, quantity on hand, and restock threshold, and flag any item at or below its threshold. Let users filter the table to just the items that need restocking and update an item's quantity when new stock arrives.

Retool builds on the preview canvas in real time, and the preview stays interactive while it works. Click around and test features as they appear, rather than waiting for the finished version.

Each conversation in the Chat tab is a thread, and threads are how you keep iteration organized. Instead of piling every request into one long conversation, start a separate thread for each task. One thread for the table layout, another for the filter logic, another for a new page.

Threads live on a branch. A branch is a set of changes with its own preview and version history, and it's the unit of work you publish. Create one when you want a distinct line of work that doesn't touch the published app, then publish it when it's ready, which archives the branch. That's about as much branching as a first app needs, and the threads and branches doc covers the rest.

For targeted changes, use Selection mode. Click the Selection mode icon on the preview canvas, select a component, and your next prompt applies only to that element.

Scoped prompts become useful once the app has enough components that "make the button bigger" could mean several different buttons. Selecting the component first removes the guesswork.

Step 3: Review and edit your functions

While Retool builds the UI, it also writes the data layer. Functions are serverless, strongly typed TypeScript functions that connect the app to your resources. Retool generates them as needed, and you can review, edit, or add your own.

Open the Data tab in the left panel to see all functions in the app and the resources each uses. From there, the Function playground runs a function in isolation, allowing you to inspect its output before it's wired into the UI. It's the fastest way to confirm the data coming back matches what you expect.

For anything you'd rather change by hand, the Code tab exposes the full React source the agent has generated, functions included, and you can edit it directly.

There's a guardrail built into all of this. Before Retool runs any function that adds, deletes, or modifies data, it sends a human-in-the-loop request to the Chat tab and waits for your approval. The "Ask to approve functions when previewing app" setting at the top of the Data tab controls this during preview, and it's on by default.

Every function also has to be approved before the app can be published, so nothing that writes to your data ships without someone signing off on it. That review step is worth doing properly rather than clicking through. For more on why, see how to secure vibe-coded apps, and for functions in general, the data concepts doc.

Step 4: Publish your app

When the app is ready, click Publish in the top-right corner. Before publishing, Retool runs a publish checklist that confirms two things:

Every write function has been approved. If any haven't, click Review functions to go through them.
Your changes don't conflict with the published version or with other users' changes.

You'll also define the app's URL slug here, so pick something descriptive. After publishing, share the URL with your team. Who can open the app is controlled by Retool's permissions and governance model, and the permissions docs explain how to set up access for different groups. The publishing guide has the full details of the flow.

Next steps after your first app

If you're coming from the classic builder, the comparison doc maps the old concepts onto the new ones. To go deeper into the builder itself, start with the app builder doc. And the Resource Hub covers related topics from here, including how to build your first AI agent in Retool and how to use MCP in Retool.

This article was originally published in December 2025. It was most recently updated in August 2026.