When Retool is the right answer (and when it isn't)

We’re Retool-certified and we build internal tools with it for clients — so you’d expect us to say Retool is always the answer. It isn’t, and knowing where the line sits is most of the value of working with people who use it daily.

Where Retool wins, clearly

Ops consoles over existing data. Refund workflows, order lookups, inventory corrections, support tooling — anything where the data already lives in PostgreSQL, an API, or a warehouse, and the “app” is really forms, tables and buttons with permissions. A tool your ops team needs would take a product squad six weeks in React; in Retool it’s days, and the six weeks were never going to be approved anyway. That’s the honest comparison: Retool doesn’t usually replace a custom build, it replaces nothing getting built.

Approval workflows with audit requirements. Role-based access, audit logs, and SSO come with the platform. For teams facing GDPR requests or SOC 2 audits, replacing “shared spreadsheet plus direct database edits” with an audited tool is often the entire business case.

Tools with fewer than a couple hundred internal users. Retool’s pricing and performance are built for internal scale, not consumer scale.

Where we talk clients out of it

Customer-facing anything. The moment external users log in, you’re fighting the platform on branding, latency, licensing and auth. Build customer-facing surfaces with a real framework.

Heavy client-side logic. If your “internal tool” is actually an interactive editor, a scheduling engine, or anything with complex client-side state, the visual builder becomes the bottleneck. You’ll write thousands of lines of JavaScript in string fields and wish you had a repo. (Some of it can live in modules and version control now, but the gravity is still wrong.)

Core business workflows you’ll iterate on for years. Retool is fast to build and fine to maintain, but a workflow that is the business — underwriting, dispatch, pricing — eventually deserves the testability, review culture and hiring pool of a conventional codebase. We’ve migrated tools out of Retool for exactly this reason, and that’s fine: it earned its keep for two years first.

The pattern that works

Start the workflow in Retool while it’s still changing weekly. When it stabilizes and hardens into the business, graduate it to a custom build with the requirements now fully known. The Retool version becomes your working spec — the cheapest, most accurate spec you’ll ever write.

The wrong question is “Retool or real code?” The right one is “how much certainty do we have about this workflow?” Low certainty, move fast in Retool. High certainty and high stakes, invest in code. We’re happy building either — which is exactly why you can trust the recommendation.