At the same time, it would be terrific to help the devs on low-code platforms avoid mistakes. Flag redundant data, point out when they have written sub-optimal workflows, give them easy ways to implement re-usable code blocks when the system notices they just wrote the same function twice with one parameter change. Data imports are also always a struggle, because most anyone can figure out how to get a CSV or Excel file brought into a system, but reading from a web-based endpoint, or parsing data from Word files tends to be beyond the capacity of most users, even if the system itself supports it.
During architecting phase of the application - we do estimate if nocode tooling will hit a ceiling. If yes then we explore 4 options:
- no brainer, export code and take it from there
- write custom Ui controls and patch them into your nocode tool
- write custom function and patch in the workflow engine or front end logic
- build Ui/UX using external code and use nocode to build backend process and connect front end with apis of the workflows/dbs
- generally complex algorithms - eg route optimization, would become a candidate of converting into a web service and eventually consumed in the nocode tool.
In my experience - One of the core essentials to write an application on nocode is having your sprint 0 dedicated towards a design phase.
The bigger question in my mind is quality. Almost all those apps, if they became a success within the business, eventually were given to the professional software folk in IT, who would fix them up and make them really work. At some point, low-code needs to be migrated to high-code.
So for all the smaller and newer players in the space, I have high hopes that some of them will become terrific solutions. But I don't know which of them truly understand the life cycle of a low-code app, nor do I know which of them will still be around in 5 years, so I'm hesitant to put much work into them today.