I realize this thread is already a couple of months old, but as I search for the right low-code / no-code platform, I came across it. Candidly, I’m currently reviewing a variety of tools such as AppGyver, Mendix, WaveMaker, bldr, retool, etc.
For context: my career spans several generations of code development and technology – but I’ve also focused my own, and my teams’, efforts on Rapid Application Development (RAD) tools. When mainframe developers would spend two years building mainframe applications, my teams learned APL and cranked out super slick user friendly applications in 2 or 3 months. When Windows developers were wrestling with the complexity of C++ app dev and slow compile times, my teams used Borland Delphi to create gorgeous compiled native Windows apps in a fraction of the time.
I’m looking for the same concept now with low code – and no-code with an option to tweak internals when needed – tools. It seems that the tools I mentioned, and many others, hover around the area, but seem to either fall short in one or two respects, or have a pricing model that limits practicality of the solution, or introduces a level of vendor lock-in that many CIOs will find onerous.
I suggest that the low code / no code vendor who gets this model right will win an enormous market.
It seems that tools like AppGyver, Mendix, Bildr, Bubble, etc. get the UI portion down nicely. An immediate red flag for me, though, comes up when I see that need to bind app components to either REST API’s, a vendors proprietary data storage, or only one or two 3rd party DBMS’s. API’s require coding. They can certainly offer benefits, but also limit app developers to only the functionality and data views that the APIs publish. Horribly limiting. For contrast – I urge all of you to look at the way tools like Delphi (originally Borland, now Embarcadero – brilliant beginning and architecture, but poor business practices killed their market position, and now their pricing is suicidal), and also look at Retool – I mention these both, because they follow a similar model: a simple but effective UI designer, data “controls” (grids, drop downs, etc.) that bind with data “sources”. Sources can be a data table, e.g., from any relational database, a SQL query, etc. The is NO NEED to have a developer write a REST API. You can do it / use one, when needed, but by default, it’s simply not an issue. This speeds development significantly, removing yet one more layer between the developer and the end result. I urge vendors to look at the development cycle / model for tools like Delphi and Retool.
Finally – pricing: Platforms that tie pricing to arbitrary metrics like, “number of items”, “number of rows”, etc., take themselves out of the running immediately for a huge subset of users. One of my teams is building next-generation pharmacovigilance / drug safety software, and the databases we’re using typically have millions of rows. Tools like Retool look great – but concern me greatly with runtime licensing tied to a per seat basis – that truly limits it to in-house apps, but make it infeasible to deploy for a million user publicly accessible application. Why would you, as a vendor, create artificial barriers that limit your adoption?
I urge vendors to think about the whole market, and about your user base and all the use cases. I see wonderful innovation and creative thought across the market, but a certain degree of myopia that’s limiting the potential of virtually every product in this space as of today.
Jon
But your comment still stands!