# Retool for FDEs: build internal tools in hours, and know when to go back to React

> Retool can get you a demo in your first week on a client site, but only if you know in advance where it stops paying off.

Bản gốc: https://fdetimes.net/en/tools/retool-internal-tools-when-to-use-react/

In the first week on a client site, what the client needs to see is often not a model or a pipeline. They need a screen the operations team can click into and actually use. Retool itself describes the problem it solves as teams spending days of engineering time writing internal tools from scratch.

For an FDE, that problem is familiar. You have access to the client's database, a few internal APIs, and an operations lead who wants to approve requests without asking someone to run SQL for them. Retool is worth learning because it goes straight at those lost engineering days. But you have to know where it stops.

## What Retool actually is

Retool's homepage positions the product as a platform for building, deploying and managing internal tools. Retool says more than 10,000 teams use it, and that it can connect to databases, APIs or LLMs. The official documentation divides the platform into Apps, Agents, Workflows, Queries, Data Sources, Source Control, Administration and Permissions.

What sets Retool apart from pure no-code tools is that it does not hide the code. Database queries are written in raw SQL.

Retool treats anything inside `{{ }}` as a JavaScript expression, and you can write such expressions almost anywhere in an app. You can also write standalone JS queries.

A developer comfortable with SQL and JavaScript can therefore be productive on day one.

## Building a refund approval screen

Suppose the client is a delivery company. The customer service team needs to see orders awaiting refunds, filter them by status and click to approve. The data already sits in a Postgres `orders` table.

You drag in a dropdown named `statusSelect` and a data table, then write a read query that takes the filter value from the dropdown via `{{ }}`:

```sql
select id, customer_name, amount, status
from orders
where status = {{ statusSelect.value }}
order by created_at desc
```

Next you add an "Approve" button wired to a second, update query, along the lines of `update orders set status = 'refunded' where id = {{ table.selectedRow.id }}`, and have the table reload once the query finishes.

The most common mistake at this step is attaching the update straight to the button with no safeguard. One misclick becomes one wrong refund. If anyone who can open the app can press the button, the tool you just built has become a security hole.

The minimum fix starts in the SQL: add `and status = 'pending'` to the `where` clause so an order cannot be approved twice. You can also build an extra safeguard yourself, such as a `reasonInput` field requiring the approver to give a reason, and add `and {{ reasonInput.value }} <> ''` to the update so it writes nothing while the field is empty.

Do not assume the platform does this for you; read the Permissions section of the Retool documentation to restrict who can use the approval function before handing the app to the whole team.

The component names here are only examples. Everything inside `{{ }}` is JavaScript, so you can format amounts, hide the button on rows already approved, or build display strings without leaving Retool.

With a screen this size, the operations lead can have a tool running on real data after a single afternoon. The biggest value here lies in the feedback loop, not the screen itself.

They use it for a few days and tell you where the real process differs from the original description, before you have invested in the wrong architecture.

**Điểm mấu chốt:** A quickly built internal tool is valuable because it gets you real feedback weeks earlier.

## Three limits to see coming

The first limit is the interface. Retool ships with a great many components, but when they fall short, say the client needs an interactive delivery route map that works in its own particular way, you have to write a custom component. The documentation states that custom components must be written in React and TypeScript. From that point you are writing real frontend code, with a build and with maintenance.

The second limit is infrastructure. Every Retool plan allows self-hosting, which matters for banking or healthcare clients whose data must not leave their systems.

But production self-hosting is deployed on Kubernetes with Helm, and some advanced self-hosting features are available only on the Enterprise plan. If the client's IT team has never run Kubernetes, "built in a few hours" can turn into weeks of waiting on infrastructure.

The third limit is users. Retool prices builders, internal users and external users, such as the client's partners or customers, separately.

When the request shifts from "a tool for the operations team" to "a portal for partner drivers", the cost and permissions problem has changed, and you should say so plainly to the client before they find out for themselves.

## Don't let speed turn into debt

The familiar complaint about low-code tools is that the app works but nobody knows who changed what. Retool's answer is Source Control: apps, workflows, resources and themes are managed through branches and pull requests.

Retool also promotes a governance model in which business teams move fast while IT keeps full visibility, so nothing has to be rebuilt from scratch before going to production.

For an FDE, this is the most valuable detail at handover. A Retool app with a clear pull request history is something the client's engineering team can take over. An app that only one person knows how to change is a problem they will carry after you leave the project.

## What to learn first

Get solid on SQL first, since almost every Retool screen starts with a query. Then enough JavaScript to write tidy expressions inside `{{ }}`. Leave Kubernetes and React until a project genuinely needs them.

On your CV, do not just write "knows Retool". Write something like "built a refund approval tool on Postgres for the operations team in one day, handed over via pull requests".

When reading an FDE job description, check whether it mentions building internal tools or rapid prototyping for clients. If it does, that is where to lead with this example.

Retool does not replace writing software. It gives the client something to try in your first week, and your job is to know when to stop and write real code.

**Thử ngay tuần này:**

- Create a Retool app connected to a test Postgres database, write a query with a parameter taken from an input field via &#123;&#123; &#125;&#125;, then add a button that updates a status.
- Draft a five-question checklist for discovery: where the data lives, whether self-hosting is mandatory, who the users are (internal or partners), whether bespoke UI is needed, and who approves changes.
- Turn on Source Control, edit an app on a branch and open a pull request to get used to the review process.

## Nguồn

- [Build internal software better, with AI. | Retool](https://retool.com/)

- [About us](https://retool.com/about)

- [Retool Docs](https://docs.retool.com/)

- [Queries and code quickstart | Retool Docs](https://docs.retool.com/queries/quickstart)

- [Build custom React components | Retool Docs](https://docs.retool.com/apps/web/guides/components/custom)

- [Retool Pricing: Find the plan that works for you](https://retool.com/pricing)

- [Self-hosted deployments | Retool Docs](https://docs.retool.com/self-hosted)

- [Source Control documentation | Retool Docs](https://docs.retool.com/source-control)