Where Low Code and No Code Work: Part 2 - Risk

I wanted to add an addendum to my last post on the scenarios where LCNC actually works. But, it is tangential enough to merit a separate post.

One thing I had omitted was that these solutions can also work for fairly simplified tasks. And as I debated on whether or not I should have conceded a bit more on that and added it to my list of scenarios where it worked I recalled 2 other issues:

1. Security
2. Vendor Lock-In

Even for incredibly simple applications, most of these are web applications. So, if you're running a business on these Platforms, then you're also dependent upon these Platforms to be safe an secure. And while they generally are safe and secure at the time that they launch, security is an area that evolves. What is considered safe today is not guaranteed to meet the necessary level tomorrow.

So, even if your app is incredibly simple and can be easily managed within the scope of an LCNC Platform, you are beholden to the Platform owner for security updates. Maybe those are automatic. Maybe they require you to rebuild. Or maybe they never come. 

Most security vulnerabilities are simple enough to address. But any vulnerability requires someone to actually address it. And security fixes aren't the sort of sexy revenue generating things PMs and other executives like to prioritize in a lot of organizations. And, if you're using a LCNC Platform because you're not skilled enough to write the code yourself, you're likely also not qualified to even evaluate if the Platform is secure enough for your needs in the first place. Let alone skilled enough to keep on top of whether or not your platform is keeping up.

And then the segue; what happens if the company becomes inactive or goes bust?

A lot of the products run on top of a platform. They don't produce code which you own and can deploy or maintain on your own after they're gone. They also DO have to pay real developers to maintain the software and a number of other positions as well as other costs like real estate, utilities and hardware operating costs. All of this means that they either need a large base of perpetual subscribers, or they need to charge large sums of money which may encourage people to simply go elsewhere.

Alternatively you could try and find something open source. But, open source means no advertising and less likely to get support, unless the support is funding the development. And in either case (open or closed source) there are risks that development will stagnate or the company will go bust. And when that happens you're application could simply disappear over night.

So, again I say, the scenarios where it works are prototyping and for people already dependent upon an existing platform with it's own LCNC support where you're either a partner or a customer.

For prototyping, you're already building something throw away. The risk of the platform going under mid-development is low because you're not dependent upon it long term. And if you're a partner or a customer, you're already invested in the company providing the Platform, so you've already bought into the risks associated with the company going under.

Also, you're likely using this company as a means to an end which isn't software development. And you likely DO know that industry well enough to make an informed decision about the company you're anchoring yourself to, which should hopefully help mitigate some of the risk of the company being a massive gamble.

In short, the target audience of generalized LCNC platforms is generally the general public who are not well enough informed about software in the first place to make well informed decisions about LCNC platforms or the companies that operate them. And this really makes them only a good investment for prototype like work loads.

And the only other worthwhile opportunity I identified would tend to mean working within an industry where you are likely to have some idea about the proficiency of the company you're choosing as your LCNC provider and possibly already invested in anyway making it a completely different proposition. 

I'm sure there are other use cases out there, but not likely any at enough of a scale to consider.