Retool Review-Is lowcode production ready?
Summary
Are Retool apps production ready? Yes, if you are comfortable testing your app using Playwright or similar test automation tools— Retool does not have native testing support (there is a closed beta for this feature). If you are not able to use these testing tools, I would not recommend using Retool apps in production. Nonetheless, I highly recommend Retool for prototyping.
UPDATE : Here is an example of tests we wrote for our app.
Contents:
- Background
- Deal Breakers
- Gray Areas
- Pain Points
- Highlights
- Verdict (in-depth)
Background
Last month, I built a prototype of an admin control panel to manage our users in Retool. Until now, I have used scripts and queries to create, bootstrap, and update user accounts. It worked but was error-prone, especially with copying the user data from the customer onboarding process. The nail in the coffin was the product key management. Initially, we gave our users one key per install, but our users wanted multiple installs. Therefore, the number of product keys will change unpredictably and will be uncoupled from our user base. We needed a way to have someone non-technical create and manage keys. I could spend a week or two building, testing, and iterating an admin control panel from scratch, but I don’t have the time, nor will the page be in front of our users generating revenue. My initial approach was to have a contractor build something, but a friend mentioned Retool, and I thought it was worth a try. A week later, after about 8 hours of work, I had a usable beta version.
Retool lets you build UIs and connect them to APIs and databases with minimal code. Their platform targets developers who want to create control panels, dashboards, and other expert tools but don’t have the expertise or staff to do so. But if you want to build for public use (unauthenticated users) then you have to sign up for the expensive Business or Enterprise plan. The Business plan costs at least $50 per month (if you have one admin user and no other authenticated users). However, Retool supports multiple databases (SQL, PSQL, mongoDB, etc.), REST APIs, RPC, and frontend scripting via JS. Perfect for my use case.
After eight hours, I could do everything my scripts and queries did: list users, update users, create users, create product keys, and deactivate product keys. But along the way, I faced quite a few issues and headaches, not the least of which was that the testing feature was in closed beta. I’ve organized my learnings into deal breakers that may prevent you from using Retool; pain points you can overcome, and highlights.
Deal Breakers
No Credential Rotation
Retool does not allow you to programmatically rotate DB usernames and passwords. Nor does it enable server API keys to be rotated. You have to go to the resources page and manually update the DB and server info, which is tedious and error-prone. This may not be an issue if you have one DB and server or if you don’t have automatic credential rotation setup. But if you do, Retool will break every time your credentials are rotated.
- This is an issue others have pointed out: https://community.retool.com/t/allow-database-password-secret-rotation-programmatically-via-an-api/5069
Expensive Per User License
The user licensing arrangement is bonkers to me. I think it unnecessarily limits the use cases for Retool apps.
Every plan triples the price for users, Retool will eat your margins. Even for internal tools it is problematic. This forces everything you build in Retool to be a demo or proof of concept.
Why not a usage fee?
Worse, if you need just one feature offered by the other plans, it’ll be very expensive. I need the multi-release feature for testing — for that one feature, I’ll go from paying $0 for our three users to $15 a month. If I need a feature from the business plan, my costs will triple to $45. The app will remain the same for my users (plans mainly include dev-ops features). My job as a developer gets more manageable, but my users have to pay three times more for it.
Expensive Public Access
“Public apps are only available on Retool Cloud with Business and Enterprise plan,” and those plans are expensive. At minimum $50 per month ($600 per year) for an app that has only one admin (standard user) using the Business plan. That’s a lot for hosting, especially as the app matures. Later in the development cycle you will use Retool less for editing and more for maintenance and hosting.
They Keep the Code
Not a suprise but you can’t export your app’s HTML, JS, CSS, and Queries. You can export Retool as JSON to share with others.
Gray Area
App Data and IP
Retool does not claim any rights to your app or its data except for:
- Maintaining and improving Retool
- Fixing issues — security, bug, and support
- Following the Law
For anything else, they need your written permission. These limitations look good, but there is a gray area in the phrase that grants you control of your app’s IP:
“Customer will own all Customer Data and Custom Apps, but excluding the components of the Services”
What do they mean by components? Does this you own the organization and structure of the app but not the individual UI elements, the hooks that connect the UI to your queries/scripts, and the other components that Retool provides? The app is useless without all that.
Nonetheless, I don’t see Retool running away with my little startup’s admin tool — but you may be in a different place. Consult a lawyer.
Pain Points
Need a Wide Monitor
You need an ultra-wide monitor; the retool editor has two panels — the side panel where all the actions live (DB/APIs scripts, HTML elements, etc.) and a central panel where your app lives. The problem is that these two panels generate two more panels. The side panel generates another panel when you select a DB or API and want to edit the query or request. The main panel opens a panel whenever you want to edit an HTML element. Navigating these panels was hectic even on my 34-inch display.
This is what editing a query that fills a table will look like.
On the left is the code tab, which has the query, and then it opens another tab, which has the actual query. In the center is the UI. On the right is the UI tab — in this case, the table, its properties, and event hooks.
It is a mess, and unfortunately, you will run into it often. During frontend work, you constantly figure out which buttons, forms, etc. fire which events. This is an easy task if the project is structured and organized well, but there is no way to structure or organize your UI and scripts in Retool. Instead, you have this repetitive and exhausting dance of going from the UI, selecting an element, checking which query it fires, going into the code tab, and debugging/editing it. So get a big monitor — it was only tolerable on my monitor but not my 15-inch laptop.
I wish Retool would:
- Remove the nested tabs — the code tab should automatically hide or minimize when query or script is selected.
- Add a dependencies section to the query/script tab to find which UI elements fire the script and which ones ingest it. Ideally, the editor should highlight the affected UI elements while editing a script.
No Native Testing Support
The testing feature is in closed beta. As it is, there is no way to test Retool from within Retool. I used Playwright and a dummy account to test my control panel. It took quite a lot of work. The UI is not made with testing in mind (no test IDs, there are layered elements that steal events, etc.), but it does work. It runs in CI too. However, the Playwright tests are all end-to-end tests. I have not found a way to write unit tests for individual queries or scripts in Retool.
Retool has not said when they will release the testing feature — it has been in Beta for almost two years now—, but it looks decent. It seems to offer support for unit and end-to-end tests. There is support for CI but only for on-premise Retool deployments — comically, the tests in CI use Playwright.
- https://docs.retool.com/private/testing#sample-unit-test
- https://docs.retool.com/private/testing-in-ci
Contact support to get into the closed beta: https://docs.retool.com/support
Discussions:
- https://community.retool.com/t/anyone-working-with-automated-web-testing-of-an-app/26926/5
- https://community.retool.com/t/how-to-add-unit-test-cases-on-retool/10548/4
Grid System is Annoying
Retool has a grid system that you can snap UI elements too, but Retool’s grid snapping is unintuitive and can’t be turned off. They are working on it. But for now, you have to deal with off-centered elements, blank spaces that can’t be filled, and, if you have hidden elements, elements displaced by seemingly nothing.
Counterintuitive Drag & Drop
The blue rectangle around the element is only for resizing. You need to click on the element’s name to move it. I found this incredibly counterintuitive. Every time I returned to Retool, I’d forget and spend a few minutes circumnavigating buttons and trying to get the drag icon to appear.
It’s Live
All the buttons, queries, and requests are live while you are in the editor. This led to many bad queries and requests hitting my staging environment. So when you are dragging that submit button into the perfect place and accidentally click, it will fire a submit request to your server and trigger all the other UI events. Resizing a table, and you accidentally click the delete button? Yes, that row is deleted.
This becomes extremely annoying when alerts and other UI is hooked to these events. Editing becomes a minefield of accidental clicks, alerts, invalid form inputs, and data pollution because there is no way to disable JS while editing. You may need to set up a separate environment or don’t connect anything until you are absolutely certain nothing bad will happen.
Retool should create a way to disable events while editing, but they don’t seem to be working on this change.
Then there is the script/request “preview” button. This helpful but poorly named button is there so you can easily test your queries and requests. This button gives instant feedback because it runs the script. It does not preview it, it sends an actual request to the DB or API. Be careful.
Variables Have a Confusing Interface
It is excellent that Retool lets you create variables, but they don’t return values. They are objects that wrap values. This caused me pain, but I understand why they did it — it avoids insidious errors caused by unintended mutation.
So my_var is an object my_var.value is the actual value. Be very careful when using variables in conditional. I often did my_var > 0, which is always false, or worse, my_var != undefined; it’s always true. This is a failure of Retool; they should update their editor to catch this common mistake.
{
"pluginType": "State",
"id": "example", // variable name
"persistedValueKey": "example",
"persistValue": false,
"value": 1,
"_desktopMarginType": "",
"_mobileMarginType":" "
}Query Editor Has No Linting
That’s right, Retool’s query editor (at least for MongoDB) is no better than shell. No warnings on syntax, types, operations, etc.. I had to write and run my queries in Compass and then paste them into Retool. Otherwise, it was a tedious trial and error made worse by the editor not displaying the actual error. See below.
Query Errors are Unhelpful
Some query errors are hidden; if you have an error in your DB query, Retool will just show a “Error” message and not tell you what is causing it. You will need to go into the browser’s inspector and check the JS or Network logs — now you need two monitors.
Limited Federated Login
Users can log in to your app with GMail or create a custom login with their email address. The options are sadly limited, but the Enterprise plan supports SSO.
Mongo Specific Issues
Retool does not handle nested JSON, i.e., you can’t display a nested JSON object in a table column. You need to flatten the nested JSON before sending it to the UI.
Retool can’t create a form from MongoDB collections (unlike SQL/PSQL). You would use this to create an update or create a form. A workaround is to query that collection, create a table from the results of that query, and then create a form from that table. The table will create columns with appropriate types, and the form will turn those types into input types. Finally, point the table’s submit event to the MongoDB query.
Retool uses MongoDB’s Extended JSON V2 with no backward compatibility for V1. Your V1 queries may not work in Retool without a migration.
Dates are not automatically converted — this may not be just a MongoDB issue. Maybe I’m expecting too much but I thought this would be handled by Retool’s parser (activated by the double curly brackets). To convert JS dates to MongoDB dates:
{ "$date": {{ (new Date()).toISOString() }} }Highlights
Supports Multiple DBs
I’ve tried only MongoDB, but the SQL support seems even better. Most generic queries are built in — no coding needed. You will need to transform the result if it contains nested JSON. Retool lets you add transformations right after the query and return the transformer’s output as the result. Plus, it has specific places to put success and error handlers — I recommend using this to print out error messages while you are working on the query; you won’t need to depend on the flaky default error display mechanism.
Unfortunately, they don’t offer an abstraction layer on top of the DBs — you will need to write separate SQL, NoSQL, etc., queries for each DB.
Create Tables Directly from DB/API Responses
Once you have a query and the necessary transformations, you can pipe them into a table during the table creation process, and Retool will create a table with the correct number of columns. The column data types are not always perfect, but they are close enough, and it is easy to change them later, e.g., if you need filtering to work, etc.
Create Forms from DB/API Responses
You can also create a form from an insert query. Retool will see the needed parameters and translate them as best as possible to equivalent input types. It handles int, strings, and dates well — struggles with enums. But again, easy to change and much faster than coding from scratch.
Sadly, this is not supported in MongoDB, but you can create a form from a table and this work around will generate a form that has the correct types for your insert query:
- Create the get query.
- Create the table from the get query.
- Create the form from the table.
- Point the form submit the event to insert query.
That is the workaround I used, and I may write about it if anyone is interested.
Premade Scripts for Common Tasks
Retool has prebuilt solutions for common tasks:
- Copy/Paste
- Show/Hide
- Show Notifications
- Etc.
Add a button to the page, click “+” in the “Event Handlers” section, and select the “Action” dropdown.
Auto-refactors
When you change a variable name, data field name, UI ID, etc., the editor updates all the dependencies. This single feature makes working in Retool a pleasure. You never have to worry about accidentally breaking something. The editor will refactor for you or prevent you from making the change.
User Role System
There’s a built-in user role system with groups and permissions. You can control which pages can be visited, queries run, etc. But this is only available on their Business ($50 / month per standard user, $15 / month per end-user) and Enterprise plans. The free plan only allows you to specify who is an admin, can edit the app, and is a regular user.
Version Control
Every change you make is tracked in a release/history tab. You can scroll through that tab and revert to prior versions. The downside is that the commits in this tab have vague names. It is hard to tell which commit did what. Even harder to tell how many changes are in each commit since it seems Retool randomly saves the state of the app. This is nice to have, but the bare minimum.
The release feature, which is not in the free version of Retool, allows you to create releases, compare diffs between releases, and revert to releases. That’s what you probably want to use for rollbacks and version control.
Verdict
It was a good decision to build our admin control panel in Retool. I got something off the ground quickly without taking time from more important projects. My only regret is the lack of testing and not going in with a testing plan. I built it without TDD — the excuse I told myself was that this wouldn’t work, and I’ll be scrapping it in an hour. Without TDD, my experience was stressful and uncertain. But we just finished the test suite in Playwright, and it is running and working in CI. Writing the test suite did take much longer than expected due to UI not being test-friendly—I had an intern do it and it took them two weeks. All in all, I recommend Retool.
