How do you judge how capable a 'no code' tool is?

I have spent my entire career building a variety of low and eventually no code platforms. As there are many 'no code' type tools being released, its easy to be confused by the feature lists and other hype that the marketing departments put out.

When I look at a tool, I judge it on two axis:

• how easy/intuitive is it
• how capable is it. said another way, what types of problems is this tool capable of solving.

It stands to reason that the tools that are the easiest to use also only can deal with more simple use cases. Now, if you have a simple use case (like doing some information capture and basic routing) a simple tool might be all that you need. But for a more complex use case (like controlling industrial machines or making nuanced business decisions) - you need a tool that is more capable.

One obvious solution to being able to do more complex things is to allow the user of the tool to write code inside the tool. This opens the power of the language chosen to handle the more complex cases. However, doing this ruins the value proposition of why you were using a tool like this in the first case. Writing code in this environment produces brittle, hard to maintain and [MOST IMPORTANTLY] scary (to business user) software.

So, if we eliminate 'low code' as just a bad paradigm (I wrote a post on this previously), how can you tell how quickly you are going to 'hit the wall' with a platform.

There are a number of things to look at including: how well does it integrate (inbound and outbound), is it extensible, how does it produce api's, etc. However, the primary place where tools start to show how capable/limiting they are is how capable/intuitive are they at dealing with structured and unstructured data.

All the platforms share common elements. They have pieces that do things (often called steps or tasks), places where decisions are made (rules or routing) and ways to get and store data. The number of steps and the flexibility of the rules matter - but - complex problems involve complex data - often coming from other systems.

Can the system use existing data structures? Does it make you convert the data into native formats or (gasp) flatten the data out to use it. How does it deal with lists of data and nested lists of data. Does it include ability to transform data from one structure to another? What tools does it have for iterating through a list of data. Does it place restrictions on what the data in lists look like? Can it combine data from multiple different structures. etc.

Having written 4 of these platforms (appglue being #4) the decisions around how data is structured, addressed and manipulated are by far the most important structural choices that are made. More 'steps' can be added later. Additional 'rule' capabilities can be added. The UI can be improved. The way the tool manipulates data is core and either a foundation for flexibility or a concrete ceiling.