This third bucket is what’s interesting: if you’re talking to a developer, low code is a completely different concept than if you’re speaking to someone with experience with no-code tools! On the developer side, low code requires dev resources. To avoid being lumped in, you’re saying we’re not low-code! We require no developer resources, just give this to your business folks and they’ll build whatever they need themselves! You don’t want to be bucketed in the low-code side of things. On the other hand, no-code folks are worried about power, will this tool be able to do everything I need it to do? Is it actually as powerful as what I can build with in house developers?
The reason I bring this up, is that this is another example of how the name “no-code” is doing us a disservice. Most “no-code” tools today have such a diverse user base that custom code is necessary to serving a lot of those use cases–they’re all actually low-code tools (if we follow our naming logic).
Therefore, we’re lumped with a bunch of developer tools that have very little to do with our goal of letting users create their own software. And may explain why some companies –top down companies especially– have to aggressively position themselves against a low-code category!
Note: this is my monthly allowance for complaining about the word “no-code”, thank you for indulging me!
PS A huge thanks to Stephen O'Grady (@orishnal) for giving the newsletter a review every week before it goes out :).