Program…no-code? Looks like a “contradictio in terminis”, but is it? The difference is how you program, using code like JavaScript, NodeJS, Angular etc. or connecting dots (modules) with arrows (connections). In both no-code and apps the logic to do something has to be designed, developed, tested and supported.
Monday.com, as any other platform I know, can’t do anything we (as users) come up with. There are times you need to rely on an external system to do things for you. That’s why we have API’s. The same monday.com API can be used in Intergomat / Zapier or monday (marketplace) apps. So, what is the difference.
Security; when using no-code platforms you have to approve the connection between them and monday.com. The same is true for apps (you have to approve the scope). The difference is that no-code platforms store your credentials (whether in a token or through another mechanism). Well developed monday.com apps do not store these credentials or tokens as they get a “60 second to use” token every time monday.com makes a call to the app. Apps win!
Costs; no-code platforms are offering free usage up to a defined amount of actions. When you get over this limit you pay a monthly fee. Third party monday.com developers, like me, don’t work for free either. It is important to understand that some marketplace apps are based on a subscription model, where others are using a one-time fee model. Who wins?: it depends!
Ease of use; clearly no-code platforms are easier to use than coding starting with an empty text editor. The app developer might use a framework so large parts of the code can be re-used, but for a single person that needs a given functionality no-code is easier to use. No-code wins! (unless you are using experienced 3rd party developers).
Supportability; I have seen many case where no-code scenarios grew over time in complexity and there is hardly any documentation. What is the person developed this leaves the organization? Apps developed by 3rd party developers are better documented and supported by that developer (it hers/his living). Apps win!
Specific use cases; if your use case is very specific to your business / process no-code seems to be a good solution. On the other hand: your use case might be not as specific as you think. There always seems to be a “clone” of your use case out there. If your use case can be made more generic the costs of specific apps comes down and the other benefits listed here starts to work for you. Who wins: it depends!
You might find this post opinionated, if so please take the time to reply so we all benefit from a good discussion.
Thanks for the insightful post here! I appreciate you sharing the knowledge here, and I’m sure other users will find it useful to see the perspective of someone who’d built an app as well and has some experience using no-code platforms. It’s a rare combo
I agree that at the end of the day, each use case and workflow has its own context and story, and your choice of achieving the end result should depend heavily on the multitude of factors that come into play there. Thanks for sharing some of the points that can help making a decision easier!
EDIT: Just something I’d thought of after giving a full read. I’m not quite sure if the topic title clearly outlines what your post is about - it seems like you are talking more in the vein of pros and cons for Apps vs No Code. Perhaps you could consider changing this to be more in line with the content of your post?
I am very excited about this thread that you’re starting here! I 100% agree with everything you’ve said and I really appreciate all the thought you’ve put into this. You covered pretty much everything there is so touché, dear sir
Still, I would like to add just a couple of thoughts about no-code platforms (like our own Integromat) :
no-code platforms log their actions by default so it’s easy to see what each run did/created/changed - there’s the benefit of “monitoring”
when there are some changes in particular API, no-code platforms update their apps - we could say they win in terms of “maintenance”
they can be used for prototyping and testing ideas before a custom code is built
Ok, I think that’s it for now Happy Friday, folks!
Oh, thanks so much for taking the time to add on to this thread, and I love your points! Actually, I do use Integromat for prototyping and seeing if something a bit more custom can be achieved via the API, so thanks for providing that for me and our users
Much like @AlexSavchuk, we often use Integromat as a proof-of-concept platform before building a custom app. It’s a quicker way to test out the business and technical requirements than coding an app and far less expensive to experiment with than custom code. We can fully test out how things should flow end to end, what should trigger what, etc.
I think the only drawback @Michaela_Staffova is that we can’t execute custom code snippets like JavaScript in Integromat. If there’s a way to do that without calling an API, let me know!
Not that I’m part of the Integromat team, but it seems like you could combine Integromat and Google Cloud functions to run code snippets via Integromat:
Perhaps this one could do the trick for you? Some functions are implemented within Integromat’s own arsenal of functions as well, so that might be something to look into.