writing
the power-user tax
Why every Retool app you've used was exhausting — and who's really paying for it.
Retool is one of the best-designed products I've ever seen.
For the person building the tool.
For the person using it every day, it's one of the most exhausting.
Every Retool app I've worked in has the same shape. A builder — a PM, a founder, an engineer moonlighting as an ops lead — loves the experience of assembling the UI in 40 minutes. They drag a table onto the canvas. They wire up the API. They publish. They feel competent.
Then they hand it to a team of 20 ops people who will spend the next five years clicking through a Frankenstein of components for 40 hours a week.
Do the math.
Builder time: 40 minutes. Once.
End-user time: 40 hours × 20 people × 50 weeks = 40,000 hours.
Every year. Forever.
Retool optimizes the wrong side of that equation. And so does every low-code platform in the category.
Three things give it away.
Components default to power-user density. Drop a table onto a Retool canvas and you get every column visible, sortable, filterable, with no sensible grouping and no truncation. The builder thinks "wow, it just works." The end-user thinks "which of these 23 columns matters?"
Empty states are usually blank — because the builder never saw one during setup. They had test data. The end-user, opening the tool on Monday morning after a weekend of no tickets, sees a blank rectangle with a generic "No data" message and a vague sense of unease.
Keyboard navigation and bulk actions are the exception, not the default. Every end-user workflow becomes a click marathon. Select. Click. Modal. Save. Next row. Select. Click. Modal. The muscle memory a good tool builds in its users — the flow state of a power user on their third cup of coffee — is rare in Retool because Retool's defaults don't build it.
The pattern isn't Retool's fault, exactly. It's the whole low-code category's fault. These platforms are sold to builders — the people who sign contracts, pitch tools to their teams, post on LinkedIn about how they shipped an internal app in a weekend. The person who uses the tool every day isn't the customer. They don't have a seat at the procurement table. They just absorb the cost.
A better low-code platform would protect that cost.
It would default new tables to a 4-column readable view and force the builder to opt into more density. It would make inline editing the default, modals the exception. It would ship bulk actions on every list component without configuration. It would generate sensible empty states automatically from the data model. None of this would slow the builder down. All of it would protect the 10,000 hours of end-user time downstream.
The low-code platform that does this next is going to eat Retool's lunch with ops teams — not because it's more capable, but because it respects the side of the equation that actually has the hours.
If you're building internal tools right now: whose time are you optimizing?
If it's the person who signs the cheque, you're making a business decision. Fine.
If it's the person who uses the tool every day, you're making a different one — and most products get this backwards.
— Chris clarai.io