Ask Cloud Architech
        Logo Ask Cloud Architech
GitHub YouTube Medium Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

Does Low-code / No-Code Really save time and money?

I am a software developer. I write code for a living. You should know this before reading any further.

Ok, with that out of the way I’d like to have a pretty serious talk about no-code/low-code solutions and how I think they actually waste more time than what they save. They may even cause more bugs than what they prevent.

OK, But First, What is No-Code / Low-code?

low-code is like building blocks
low-code is like building blocks

Before I begin my rant, err - findings, maybe I should start with a brief definition of what the heck I’m talking about. No-Code / Low-Code apps are essentially tools that allow people (non-engineers) to make solutions to problems by using a UI instead of writing code. Solutions like this range all the way from something like Zapier (a tool that allows you to make workflows between cloud services) to full scale CRMs like Salesforce or Hubspot that allow you to configure the entire experience through their administrative interface.

The important thing to know here is that these tools are absolutely EVERYWHERE. It’s all the rage right now. Every IT department on the entire planet is drooling over the idea of people just being able to buy solutions and make them work without having to write any code. Because, you know, writing code is hard, and the world is in a place technologically that we really shouldn’t need to do hard stuff anymore.

This Sounds Great, Let’s Build Everything Low-Code!

Developers are EXPENSIVE, and all they do is jump from job to job on their mission to maximize their salary. All these no-code solutions are the answers to everyone’s prayers! NO MORE DEVELOPERS!? That’s amazing! Just imagine all the money we will save!

And you know what? At the surface that does appear to be the promise. No developers necessary. All you need to do is buy an account with one of these tools and then start configuring. In no time at all you can have all your totally custom business logic set up in your app. Just click all the right buttons in just the right sequence and TADA! You just made yourself a thing with no developers, just administrators.

If you look around there are no-code solutions for almost everything. Here’s a list

I think you get the point.

But before you start thinking that this article is going to be just me trashing all of these tools, let me throw you a curveball. Each of these (and all the others) are absolutely GREAT applications. I even use some of them personally.


And I think that might be the key word here. These tools have a ton of functionality if you are trying to get off the ground with a simple concept. They serve the purpose of providing quick and somewhat generic solutions for common problems. Even tools like Zapier that sell the idea of “Connect anything to anything” don’t actually connect literally everything to everything. They actually connect a subset of popular platforms in an even smaller subset of popular ways. Because at the end of the day, a developer had to code all this, so you don’t have to (but that’s a different topic).

OK, Whats So Bad About Using No-Code for More Complex Scenarios?

I think I’ll finally get to my point now. We’ve covered what they are and where they help, but now it’s time to talk about where they hurt and where many businesses miss the point.

As soon as you lose the use case of “small business looking for quick solutions”, you will begin the see the problems with these tools. Let’s break them down

Configuration Takes Time

If there’s one thing I know for certain, ALL of these tools make a really solid sales pitch. Configuration takes way less time than writing code. I guess that’s partially true but only in one situation: if you don’t know how to code.

That’s right! The sales pitch is perfect for the audience! The person who doesn’t know how to code is looking for ways to do things without writing any code. This tool is faster because it requires no code. Of course it’s faster because for a non-developer it’s literally the only solution beyond hiring someone else to do it.

But… if you are a company that has any type of resources, you could hire someone to do it. That someone that you hired could make the thing you want in less time than it would take to do it with the no-code solution, and it would be more secure and cheaper in the long run. Honestly, I’ve experienced this so many times I’ve lost count. Seeing a company burn time trying to figure out how to get the low-code thing to do what they want just kills me. Especially when It’s something that could be done with only a few hundred lines of code. I’m not exaggerating.

Which gets me to my next point.

Custom Means No Compromises

Even if you could use a no-code solution to solve all of your problems, you will probably find that it’s not perfect. You probably have to make some compromises to your vision or do some workarounds to make the problem solvable with the no-code solution. Adjusting your problem to match the pre-made solution is never a good idea.

That’s probably all well and good if you are a small business getting off the ground, but if you are a larger company you probably don’t want those types of workarounds in your set-up (also known as hacks). If you didn’t use the no-code solution and instead built a solution that exactly solved your problem you won’t have to deal with the bugs later down the road. On top of that, having the solution in one tight package instead of a ton of little widgets and configurations will make maintenance down the road waaaay easier.

Which… lead me to my next point.

How Many Tools Do You Need?

When it comes to these low-code solutions, probably just one of them won’t be the unicorn you are looking for. In many cases you’ll need to tie several of them together to get the final outcome you desire. At some point the “simple” solution starts to look exactly the opposite. Unraveling all the config to figure out how something works a year later become incredibly challenging. It might work right now, but will you honestly be able to make changes to it later without spending a TON of time relearning exactly what you did?

Which… leads me to my next point.

Where’s the Documentation?

Most well written custom apps have documentation. If you have developers that are any good at all, they will either write docs for their apps or even maybe write apps that document themselves. With no-code solutions you don’t get any of that. At best, you might get a visual that shows how your integrations tie together, but most of the time its just going to be a bunch of screens of config that someone else will have to unravel after that first admin leaves for a better job.

Which… leads me to my final point.

Specialists are Also Expensive

The whole “developers are expensive, admins are cheap” thing is a pile of you know what. I’ve personally seen a single developer make a focused custom app that would take three administrators to make in a low-code solution. So… let’s do some math. Actually I don’t think it even takes any real math. Three administrators costs more than one dev any day. Additionally, some low-code application experts are in super high demand right now. I don’t think you’ll find them sticking around at your company any longer than a dev would. Plus, how long someone stays really has nothing to do with pay at the end of the day (again, another topic for another time)

It all Comes Down To One Question

I think it’s pretty easy to see that there are pros and cons to using no-code solutions. Sometimes they are exactly what you need. Sometimes they cause more harm than good. So, how do you choose? Well I think the answer to that is: After reviewing the functionality of the solution does it solve your problem easily? If you can confidently say “yes” to that question, go for it. But, if you hesitate for even a second and think a low-code solution might be almost what you need but not quite, I’d strongly advise you to avoid trying to “make it work”.