adoption vs utility/teardown series 5 of 5
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 we've ever seen for the person building the tool. for the person using it every day, it is one of the most exhausting.
every retool app we'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 5 years clicking through a frankenstein of components for 40 hours a week.
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. 3 signals show up again and again.
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 rather than the default. every end-user workflow becomes a click marathon: select, open a modal, save, move to the next row, and repeat. 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 do not build it.
the pattern is larger than retool. it is the whole low-code category. 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. capability is not what wins that shift. respect for the side of the equation that actually has the hours is.
if you're building internal tools right now, whose time are you optimizing? if it is the person who signs the cheque, you're making a business decision. if it is the person who uses the tool every day, you're making a different one, and most products get this backwards.