Could you expand on this a little? I'm using Retool now for a client, and while some parts are a little shaky, I can see how it's saved a lot of time over developing internal dashboards from scratch.
It's really great for exactly that use case, creating lots of internal dashboards from scratch. Part of how it makes it really easy is that you don't go through all the normal dev practices, and will normally connect directly to your datastores as well as any api endpoints your service provides. This creates a huge amount of deeply hidden coupling.
You'll also inevitably need to go beyond the functionality that retool offers, at which point their development experience really breaks down, and you'll have to either come up with some bespoke workflow to integrate complex custom components, or migrate away.
Despite all this I really like it as a tool, it just needs to be approached with care.
The tool spreads "code" around in a lot of different ways, like mustache templates, transformers, and orchestrations. So it would be hard to keep track of all that without the git integration. I didn't look at it deep enough to see what dealing with, for example, a change in the source data schema would look like.
I would like to understand why you think so since I am working on my own open source product which has many similar aspects as Retool, although not in the same exact domain.
It always boils down to the same thing: people think that it's a technology problem. But it's a people problem.
Software development (at scale) is not difficult because you tell a computer what to do (that part is quite simple), but because you and many others need to communicate your thoughts both to a computer _and_ humans (sometimes even themselves) over a potentially long period of time. And as if that were not bad enough, it all has to be coordinated.
These two things - sharing thoughts and doing coordination work - are what eat your resources. When doing "normal" development, you use a programming language and most likely an IDE and a VCS such as git(hub). All of these usually exist for quite some time are used by _a lot_ of people and are well understood, polished and mature. (well, of course some more than others)
But every no-code tool (or low-code) such as Retool has to recreate _all these_ by itself. This is really as bad as you having to learn a brand new programming language, an IDE and (partly) a VCS. Will they be as good as the tools that millions of people already use? Probably not.
And just to clarify the programming language part: yes Retool is sort of a programming language. Even though you can embed SQL. (You can do this in other languages too). Clicking instead of mostly typing doesn't change this fact.
Of course, all of that doesn't matter if you build something quickly and throw it away in a few month. In that case, Retool might actually pay off. But these cases are not the "hard" ones anyways and are usually not a big problem in most companies.
It seems like a bit of a mistake to look at this like a programming language instead of, say, an information organization tool like Trello.
You don't have an IDE for designing process around Trello, you talk to people and figure stuff out that works (so long as it works well enough). I think these kinds of tools fit well in places where process are the big blockers, instead of the technical details (though of course technical details can crawl back up and bite you).
(Though I do think what you're saying seems to apply more to Retool relative to more straightforward low-code platforms like Anvil)
If it is not a programming language, you cannot do everything you can possibly think of and you would be restricted.
But people _want_ to do what they have in mind, so they will work around the tool in some way. Either by employing a mechanism to still make the tool do what they want (e.g. macros in Excel) or by using another tool that fills the gap. In case 1 you now have the worst of both worlds and in case 2 you now have X tools with all the problems that a zoo of tools brings.
If, on the other hand, you _can_ describe every business rule that you can think of in that tool, then it _is_ a programming language. There is no requirement for a programming language to use text. See scratch lang for example.
Was also thinking this, feels a bit like RPA. Will no doubt generate quick returns, buzz and happy management (short term) but longer term will it be performant, scale, allow integrations between departments. Not so convinced on this but for smaller isolated projects can see it having a place even if throw away effort.
> Retool positions itself as a tool for technical folks, and you’ll need to be comfortable with basic SQL and Javascript to get the most out of it.
> An interesting reminder that PMs aren’t always in the driver’s seat. In fact, sometimes they’re not even in the car .
If you're building a technical tool for technical folks then you probably don't need product managers, until late game anyways. Though you'll probably already have a few product engineers and product designers, who fill in that role.
> Is Retool that useful? DoorDash thinks so. So does Brex. And Peloton. And Mercedes. And Tom Brad... Sorry I meant the NFL. Not sure Brady knows about Retool yet.
These claims, while true in a literal sense, always bug me in that they don't really mean anything. I actually work for Mercedes and it's so large I can't even see where my division starts and ends, let alone my area of the company (which is a subsidiary of a subsidiary!)
I'm sure a team uses it somewhere nor do I have any opinion of Retool itself. I'm also not speaking on behalf of Mercedes either. Just that it's a sort of Gell-Mann Amnesia feeling I get when reading that endorsement ;)
These endorsements as far as I can tell are very often based on someone with an @google.com address has signed up and used the tool at some point in time, rather than being an actual endorsement.
I imagine at a baseline, they have to be paying customers but I generally agree. I've signed up for a few sites that have reached out based purely on my email address. I think I once signed up for HERE Maps who kept calling me. I had to explain that I was using it in a personal, non-commercial capacity and had just happened to accidentally use my work email.
> Not only do you build internal software faster, you build more of it!
The problem isn't building too little software, it's building the right thing, making it robust, and making it usable all the while the requirements change to reflect reality and the underlying team shifts around over time. Simply building more software faster will give you more tech debt than you could've ever dreamed of.
This is a pretty bad article. PM are not the only responsible for product dept. PM have limited resources and lot of constraints in order to achieve their job. Bypassing PM is going to make things better at first but will make things worse long term.
I've already argued that Retool, is the definition of product dept. No code is great for non technical people, but Retool is targeted at technical people.
The reality is that companies which use Retool are companies which are not able to improve their product in a coherent way to also address administrative tasks. Some people then say, well it is internal so we just need an API and a shitty interface.
Retool is a good tool if you are a small company and you want to test things quickly in order to implement them or not in the future. It is bad for bad companies trying to hide their shitty prioritization of admin features. I'm pretty sure Retool will be a great financial success while being a marker of dysfunctional organization. I will never work in a company that use Retool
I gave it a try a few months ago, it seemed fine but ultimately opted against investigating further. It was cool being able to hook up my GraphQL API, but it felt slow and clunky, and didn't really meet my needs. It's obviously more modern, but you can achieve a lot of the same things with Microsoft Access or Filemaker (remember those?).
There seems to be a bad assumption in the article, which is that working on backoffices is tedious. I actually enjoy it, building bespoke productivity tools for your own colleagues is interesting work. The more common issue is that it's often painfully difficult to get a company to agree to invest engineering effort in something they think they can just buy. So most backoffices just end up being a rushed pile of CRUD screens without any real design consideration.
I think one solution here is to actually have a PM for backoffices, and invest in doing it well, rather than treating them as a technical burden.
19 comments
[ 2.9 ms ] story [ 50.5 ms ] threadIronically, using retool will inevitably generate massive tech debt in your organisation.
You'll also inevitably need to go beyond the functionality that retool offers, at which point their development experience really breaks down, and you'll have to either come up with some bespoke workflow to integrate complex custom components, or migrate away.
Despite all this I really like it as a tool, it just needs to be approached with care.
The tool spreads "code" around in a lot of different ways, like mustache templates, transformers, and orchestrations. So it would be hard to keep track of all that without the git integration. I didn't look at it deep enough to see what dealing with, for example, a change in the source data schema would look like.
Software development (at scale) is not difficult because you tell a computer what to do (that part is quite simple), but because you and many others need to communicate your thoughts both to a computer _and_ humans (sometimes even themselves) over a potentially long period of time. And as if that were not bad enough, it all has to be coordinated.
These two things - sharing thoughts and doing coordination work - are what eat your resources. When doing "normal" development, you use a programming language and most likely an IDE and a VCS such as git(hub). All of these usually exist for quite some time are used by _a lot_ of people and are well understood, polished and mature. (well, of course some more than others)
But every no-code tool (or low-code) such as Retool has to recreate _all these_ by itself. This is really as bad as you having to learn a brand new programming language, an IDE and (partly) a VCS. Will they be as good as the tools that millions of people already use? Probably not.
And just to clarify the programming language part: yes Retool is sort of a programming language. Even though you can embed SQL. (You can do this in other languages too). Clicking instead of mostly typing doesn't change this fact.
Of course, all of that doesn't matter if you build something quickly and throw it away in a few month. In that case, Retool might actually pay off. But these cases are not the "hard" ones anyways and are usually not a big problem in most companies.
You don't have an IDE for designing process around Trello, you talk to people and figure stuff out that works (so long as it works well enough). I think these kinds of tools fit well in places where process are the big blockers, instead of the technical details (though of course technical details can crawl back up and bite you).
(Though I do think what you're saying seems to apply more to Retool relative to more straightforward low-code platforms like Anvil)
But people _want_ to do what they have in mind, so they will work around the tool in some way. Either by employing a mechanism to still make the tool do what they want (e.g. macros in Excel) or by using another tool that fills the gap. In case 1 you now have the worst of both worlds and in case 2 you now have X tools with all the problems that a zoo of tools brings.
If, on the other hand, you _can_ describe every business rule that you can think of in that tool, then it _is_ a programming language. There is no requirement for a programming language to use text. See scratch lang for example.
> An interesting reminder that PMs aren’t always in the driver’s seat. In fact, sometimes they’re not even in the car .
If you're building a technical tool for technical folks then you probably don't need product managers, until late game anyways. Though you'll probably already have a few product engineers and product designers, who fill in that role.
These claims, while true in a literal sense, always bug me in that they don't really mean anything. I actually work for Mercedes and it's so large I can't even see where my division starts and ends, let alone my area of the company (which is a subsidiary of a subsidiary!)
I'm sure a team uses it somewhere nor do I have any opinion of Retool itself. I'm also not speaking on behalf of Mercedes either. Just that it's a sort of Gell-Mann Amnesia feeling I get when reading that endorsement ;)
The problem isn't building too little software, it's building the right thing, making it robust, and making it usable all the while the requirements change to reflect reality and the underlying team shifts around over time. Simply building more software faster will give you more tech debt than you could've ever dreamed of.
I've already argued that Retool, is the definition of product dept. No code is great for non technical people, but Retool is targeted at technical people.
The reality is that companies which use Retool are companies which are not able to improve their product in a coherent way to also address administrative tasks. Some people then say, well it is internal so we just need an API and a shitty interface.
Retool is a good tool if you are a small company and you want to test things quickly in order to implement them or not in the future. It is bad for bad companies trying to hide their shitty prioritization of admin features. I'm pretty sure Retool will be a great financial success while being a marker of dysfunctional organization. I will never work in a company that use Retool
There seems to be a bad assumption in the article, which is that working on backoffices is tedious. I actually enjoy it, building bespoke productivity tools for your own colleagues is interesting work. The more common issue is that it's often painfully difficult to get a company to agree to invest engineering effort in something they think they can just buy. So most backoffices just end up being a rushed pile of CRUD screens without any real design consideration.
I think one solution here is to actually have a PM for backoffices, and invest in doing it well, rather than treating them as a technical burden.