>Thing is, and this differs per market; most companies do not need anything more than endless streams of crud apps, and that is where these tools shine.
IME at least 20% of the needs of these companies are not met by "basic CRUD app programming" which is why these no-code things never really take off despite often appearing quite impressive. 80% is not enough.
Basic CRUD also implies an understanding of domain modeling and normalized relational db design. In practice these are uncommon enough skills among developers never mind users of tools like these. That's half the reason why spreadsheets business users want turned into apps are so horrendous - it's not even intrinsically a problem with excel, it's just that the relationships between the domain objects are usually confused and the data is in a mess.
I've worked for a company that market themselves with "No code". How it worked there was that we spent a lot of time understanding the users need and business domain and modelled a properly normalised db from it. Then came the "no code" part, which was a platform that made it easy and very fast to create the first iteration of the interface from the database. For those things where the mapping to some tables in the database were simple it was just a few clicks. Something like search customer and create/update customer pages takes less than a minute to create.
And you are of course right in that this will only create 80% of what the customer needs. But the marginal cost for us to create those first 80% of the application were almost zero. And since we weren't worse than anyone else with the last 20% we could deliver fast, inexpensive and still have large margins.
The mistake I think many do when they think "no code" is that they think that they can eliminate the developer and let business people just "configure" the new application. But those people have the insulting idea that the only thing that makes programming hard is syntax.
> The mistake I think many do when they think "no code" is that they think that they can eliminate the developer
Exactly. No-where did I mention you do not need (good) devs for this. They are just not writing code (in the traditional way). No/lowcode is not saying the same as end-user development, although it gets mixes up quite a bit (also by the companies selling the tools), it is not what I mean when when working with such tools.
And in my experience at least, you can push back closer to the 80% than the 100%, so sure, you don't get that last 20% (or part of it) but maybe I can convince the client they don't need it. And if they do, I would choose (maybe) another tool for the job like I said.
IME at least 20% of the needs of these companies are not met by "basic CRUD app programming" which is why these no-code things never really take off despite often appearing quite impressive. 80% is not enough.
Basic CRUD also implies an understanding of domain modeling and normalized relational db design. In practice these are uncommon enough skills among developers never mind users of tools like these. That's half the reason why spreadsheets business users want turned into apps are so horrendous - it's not even intrinsically a problem with excel, it's just that the relationships between the domain objects are usually confused and the data is in a mess.