Low code software development is not a lie -- it's a trade-off.
You gain (a) canned components / patterns for rapidly performing common tasks, (b) opinionated design that encourages one particular solution, (c) support for any issues from the underlying stack.
You lose (x) open development ecosystems, (y) general purpose flexibility, (z) ability to evolve a tool however you want and fix your own issues.
Given the above, when does low-code make sense?
When you have a common business use case, that happens frequently, and you'd prefer not to train/retain developers to deal with it.
Generally, the dominating value of low code is directly proportional to how much of your use case the canned functionality solves.
Some examples of where it's a good fit: application-application automation (provides interface glue and exposes higher-level actions), CRUD app generation (uses common design patterns to build everything the user doesn't need to change), data flow (allows the user to declare what should happen, then generates the how).
If you find yourself hacking functionality into a low-code tool often or substantially, it's inappropriate for your task.
If you're trying to use low-code to deliver a core business competency, it's inappropriate for your business.
Use it for the boring and less important stuff, that's not worth developer time. In the same way that businesses rent instead of buy carpet (because it's not a core competency), most businesses shouldn't have full in-house development teams to do ancillary development tasks.
Source: worked in UI automation for a decade+ and watched customers and the industry
As an additional point - If I have an entry-level clerk who does 2 hours of work per day that could be automated by putting a dev to work on building a solution for a month or two, it won't financially stack up. I also don't really want to pull that dev off to work on that, because I could probably have them working on better stuff.
If we could build something a bit more scrappy in a low code tool in a few days and pay $40-$80 a month in licencing, that will stack up fast. Will it be as good as the full-code solution? Probably not - but we weren't ever going to build that solution anyway and it's better than nothing.
It's a simplistic example, but there are categories of problems that low-code can solve which full-code can but won't.
Low code is actually pretty dominant in the data integration space. Tools like Fivetran or Zapier that provide point-to-point integration of structured data from a source to a target with some rules for scheduling, filter and transform. If enough people need to move customer data from Salesforce into Snowflake it eventually just becomes a platform.
You gain (a) canned components / patterns for rapidly performing common tasks, (b) opinionated design that encourages one particular solution, (c) support for any issues from the underlying stack.
You lose (x) open development ecosystems, (y) general purpose flexibility, (z) ability to evolve a tool however you want and fix your own issues.
Given the above, when does low-code make sense?
When you have a common business use case, that happens frequently, and you'd prefer not to train/retain developers to deal with it.
Generally, the dominating value of low code is directly proportional to how much of your use case the canned functionality solves.
Some examples of where it's a good fit: application-application automation (provides interface glue and exposes higher-level actions), CRUD app generation (uses common design patterns to build everything the user doesn't need to change), data flow (allows the user to declare what should happen, then generates the how).
If you find yourself hacking functionality into a low-code tool often or substantially, it's inappropriate for your task.
If you're trying to use low-code to deliver a core business competency, it's inappropriate for your business.
Use it for the boring and less important stuff, that's not worth developer time. In the same way that businesses rent instead of buy carpet (because it's not a core competency), most businesses shouldn't have full in-house development teams to do ancillary development tasks.
Source: worked in UI automation for a decade+ and watched customers and the industry