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.