however the answer still boils down to "it depends" since it intersects with different industries, and companies of different maturity stages.
making a landing page for some simple site? no code works.
need a fast crud for operations team? no code works.
creating a web app prototype to validate a simple idea? no code works.
refining a product with existing users in terms of platform compatibility, scalability, performance? time for specialists on front-end and back-end languages.
i think there comes a time when sales are coming in at the door and at that point throwing money at the problem makes sense, to move from no code to handwritten web apps and mobile apps.
i personally prefer appsmith over budibase. zapier and n8n, cool stuff too.
but in complex stuff i still come back to reactjs and nodejs.
For simple CRUD apps, internal tools, reports, spreadsheet replacement - low-code platforms - particularly OSS options (Budibase, Appsmith, and others)
As a result these solutions work just fine until the point where they trip the user up and start repeatedly punching them in the face. The user will usually try to work around the limitations and that's when it goes really badly wrong. Often the users will blame themselves for not knowing how to progress or for creating a mess.
If your needs are simple enough you might never reach that border. It's suitable for those tasks.
It's made worse by the economic incentives of no code platforms too. They try and trap the user on their platform. So, once you reach the border line the user usually has to dump the entire app and bring in a programmer to code it all up from scratch. That makes bad workarounds that much more tempting from the user's perspective and thus that's how the no code solution dumpster fires are born.
I think that a lot of the problems that general wisdom thinks are implicit to no/low code are so prevalent precisely because the barrier to entry is so low.
You get a lot of people who have never programmed anything who can basically put together something that almost works by tweaking tutorials and googling around.
But where they get stuck is lacking the programmer's mentality - of being able to puzzle around restraints (which all programming languages have) and then imagine all the worst case scenarios and test against them.
Down thread, somebody even makes the claim that low code doesn't permit for maintenance but of course this isn't true - again, it's just inexperienced users thinking that once something works once it will work forever.
And the amount of professional developers who would be willing to come in and untangle a low code mess as opposed to suggesting a "real" solution (coincidentally using their favoured stack) probably reinforces the idea that the last 20% is impossible with low code.
It's not about agendas or people being stubborn, it's just about people playing to their strengths and having their perspective coloured by experience
It may seem like a good idea to postpone such considerations. And it might even be in some situations. But complexity will still bite you in the ass even if you sweep it under the carpet and tell people not to worry about it (for now).
But if people say you can't replace a railroad consist that necessitates engineers and designs with wheel barrels that anyone can push and you say "you totally can, you just need enough wheel barrels" you're being disingenuous about the realities of the two approaches.
I think code is a great thing, just that the "everything looks like a nail" argument goes both ways
Low code is just a GUI on top of some library. I'd rather just write the code and call the library functions directly than mess around with boxes that do nothing other than limit my options.
As a rule of thumb, the only kind of job posting that should mention a low/no code solution is one for a software developer hired to migrate your current solution to real code.
And being fully honest, I've not seen basic CRUDs since college homework days. Every CRUD I've seen since has some business rules applied to it, whether these are triggers or some special field constraints.
If a business needs a basic CRUD, it gets away using a spreadsheet.
In every project I worked on, the users of the system always wanted it to do things that go beyond what the low-code system was designed for. That always required what was essentially coding, but using some clunky UI for advanced code-like functionality.
In the end, you have a system that would have been much more maintainable if you had just gone with a standard "with-code" solution.
They always sell these things with the idea that non-coders can do most of the work on the system, but that's only true for a very basic system. In my experience, it's coders that end up doing 90% (or more) of the work and it ends up being inferior to a coding-based solution.
A very nice effect of this is cross-functional collaboration—once it's possible for the team's developers to provide the right components as building blocks, then the non-developers in operations, design, marketing and product functions can compose these into full pages.
Developers are hostile to these types of solutions specifically because once you go past basic CRUD your no code solutions make everything so much harder and complicated compared to if you had of just used JavaScript in the first place.
I’m fully expecting some no code sales people here to disagree. They always do. Those same sales people will try to blame the programmers for getting in the way of saving money or being stuck in their old ways. Have a good long proper conversation with your programmers that you trust and try to understand their resistance better.