The problem with no-code solutions

No-code middleware always leads to the same ugly conclusion. It’s easier to see with a practical example - in this case our old pre IguanaX product - Iguana 6.

One of the biggest inspirations for IguanaX’s design was looking at the problems we faced with the To/From File components in the product. In our support flow we’d often find customers having trouble with these components and need to switch them to implementing the logic they needed in Lua using the translator. This explains why:

I would describe the file components resembling the dashboard of 747. All sorts of options and pull down lists. There is so much stuff that my laptop screen isn’t large enough to show the whole lot - I need to break it up into two screenshots:

Programming by selecting options in the long run turns out to be a very inefficient way solve problems.

It’s hard to know exactly what those options do. Quite often they would not so what you would want them to do.

If you think the interface looks complicated - think about the complexity of the code underneath.

Trying to alter that code without breaking compatibility becomes very difficult. Eventually one has to stop.

And yet the components would always be short of a couple of features that customers needed.

In fact it can kill off products. I can think of major competitor right now that went that route. The were acquired and now the acquirer is killing off that product because in the long run this approach doesn’t work.

The product starts simple but gets more and more complicated and becomes harder and harder to use - no one is happy in that model.

This is why designed IguanaX around the idea of never having components hard coded into the platform. Instead build very simple components in Lua and make it super easy to customize them.