No-Code, Low-Code, Mo-Code

( inspired by real people on Twitter )

This title is as close to clickbait as I fear tread. Relax, this is not a treatise to abandon all thoughts of using low-code or no-code solutions.

However, my work with CastAlum has required the development of two small custom apps. As it happens, the one use case seemed a good fit for the Microsoft Power Platform, specifically, linking Power Apps with SharePoint through Power Automate. The other required transitioning from a historic Access database (which I built as an apprentice), to a more powerful and feature-rich web app built using the MERN stack (plus a little shout-out for Meilisearch). 

Disclaimer: I’m aware Power Apps could be classed as low-code or no-code depending on how you use it, but for the purposes of this article, I’ll refer to it as low-code. And I use hyphens wherever possible because it annoys my boss.

This presented an interesting opportunity to compare a low-code development process to a full-stack one. If you think it’s a little bit bizarre that one person is doing both at the same time, you’re probably right, but such is life in an SMB…and I love it.

If you want a TL:DR, below are the three points I’d like to make:

  • Low-code doesn’t necessarily mean easier.
  • Low-code doesn’t necessarily mean low-cost.
  • Microsoft forums consist of MVPs talking to each other. 

(I’m not actually going to talk about that last one, I just find it humorous.)

Low-code doesn’t necessarily mean easier

I have been really surprised by just how fiddly the Power Platform is! Now, yes there may be some use cases that really allow you to use Power Apps as a no-code solution, but then you’re basically describing a form that feeds into a table. In this case you’re probably better off avoiding Power Apps altogether (as I have done in the past).

I’ve had issues with Power Apps and Power Automate not talking to each other without proper synchronisation. I’ve found features that have been stuck in an experimental state for years without any progress. And I’ve been amazed how much I’ve needed to turn to Googling for random forum answers, sites, and YouTube videos, as the documentation doesn’t provide the answers I’m looking for.

The reason being, that much of what you can do in Power Apps involves ‘hacking’ it. Effectively, if you want to do anything more complicated than capture and read information from a SharePoint List, then you’re likely going to need to get your head around someone else’s code to make your square peg fit the round hole that is Power Apps.

Oh and on that last point, one of the real difficulties that I’ve found while Googling is the iterative nature of the product’s development. Meaning that a solution that worked two years ago (when Flow was Power Automate by the way), may not be the best way to achieve your goal in the current product, as Microsoft could have added or removed features in the meantime.

Low-code doesn’t necessarily mean low-cost

The complexity I’m referring to leads onto this point: don’t be lulled into thinking that no developers = no cost. On the contrary, keeping my app free on the Power Platform, was one of the trickiest parts of the whole process.

There’s a few reasons for this, which effectively revolve around Microsoft trying to find a way to get you to pay for their services as much as possible. Why else would they allow you to convert to a PDF as a OneDrive action, but not a SharePoint action? This leads to the very common hack: { Copy to OneDrive > Convert to PDF > Copy back to SharePoint }

Oh, but there is an option to convert to PDF in SharePoint. Except you have to pay for it. And here’s the kicker: if you link a Power App to a Power Automate flow that has a premium connection, everyone who uses the app has to have a premium license.Yeah, that was my facial expression too. And once you start paying for licenses, low-code platforms get really expensive, really quick.

Now, I’m being slightly facetious in all of this, because if I was so sceptical about the validity of the Power Platform, I just wouldn’t use it, end of. However, the point is this: it does not follow that just because something can be done in the Power Platform, it should be. It’s not necessarily going to save you time and money, and in fact it might even cost you more than some others.

In the instance I’m working with, it’s pretty perfect, because I already have the technical skills to hack it to do what I want without paying additional licensing fees, and the fact that it ties in so nicely with SharePoint as a backend, makes my job even easier. Oh, and the app can be deployed and used instantaneously on the factory floor using a tablet as a data capture and reference device. *chef’s kiss*

Just be sure before you go down the Power Platform route that there’s a good reason for it. Because I can tell you that at least in the development process, my full-stack app has given me a lot more highs than low-code.