Mindset Hurdles When Building Low Code Apps As a Software Developer

Intro

There are two boats you can be in when building with low code solutions – either you don’t have any traditional app dev experience, or you do. If you don’t have app dev experience and consider yourself more of a “citizen developer”, this post won't help you much.

But if you do, I know how challenging it can be to fit within the box of “Low-Code”. It’s something that has taken a long time for me to warm up to, so I wanted to share some of the mindset shifts that I had to process before feeling more comfortable.

You Are Not In 100% Control

Let’s start with this spoonful of humility. One of the best things about custom app development is how capable it is – you can almost do anything with the app you set your mind to (with enough time). Things like custom interactions/processes and interfaces (UX and UI). It can feel powerful.

Now someone comes along and says “oh, use this drag-and-drop WYSIWYG app builder, it will make things way easier!”.

Suddenly your connection to the code is obscured and you have to work within the confines of the tool.

The reality is this has already been done many times before. The coding languages or frameworks you’re using are already abstractions from “true control”. What was a developer’s reaction when they were able to go from Assembly to Compiled Languages like C and C++? Or from there to Java, .NET, Javascript, or Powershell? How about one step further (where most of you probably are) to things like React, Vue, TypeScript, etc.  

All of these jumps took something complex, and added a layer of abstraction to make writing code easier. And we likely jump on the next bandwagon because we can stay out of the technical weeds.

Now, low-code tools like Power Apps, Power Automate, Zapier, IFTTT are all doing the same thing.

But this jump is MUCH larger. It makes it so easy that someone who doesn’t write code can now build apps. This can feel uncomfortable.

So, I suggest you look at it through a similar lens as what the previous advances in technology did for the development community – if you’re willing to give up some control in favor of speed and ease to build, you’ll be in good shape.

You have to live with limitations

Now that we’re willing to give up some control, that means we may have to live with some limitations. Where you may have been able to use custom code for something before, it may not be obvious how to do it in this case, or it may just not be possible at all.

Want rounded corners on your inputs? Well guess what? The Power Apps text inputs support it, but it doesn’t support rounded corners on dropdown inputs. Why? No idea. But either way, plan on having no border radius.

How about drag and drop? Not supported out of the box.

Want holistic styles for your app all controlled in one place? Easier said than done.

Need Power Automate to connect to a tool, but it doesn’t have a supported connector? Have fun building a custom connector.

Or one of my complaints with our website platform Webflow: they don’t support nested CSS classes. Can you believe it?

Now, back to Power Apps, some may see this and say, “ACTUALLY Mitch, you can support these things with PCF”. Yeah, yeah. See, the idea of these tools is to avoid code, or use as little of it as possible. So when the default to hitting limitations is “I’ll use this custom way to work around it”, it defeats the purpose of the tool, and goes against the “citizen-developer-centric" mindset that is supposed to be used here.

And if you decide to do it anyway, you’re effectively creating technical debt. Since this is sort of “coloring outside of the lines”, these things may break in the future, or be difficult for others to support if you were to, say, win the lottery and quit your job. Dramatic example, but just trying to make a point here.

It’s better for the long term if you can learn to live with the limitations.

You may change the way you approach problems.  

I love writing code and making things really great. But I often let perfect be the enemy of good.

Instead of getting lost in the weeds making animations “just right” or getting that gradient to perfectly overlay the background image so you can read the text (guilty of these things), you focus on the outcomes instead.

What is the end user actually trying to achieve? What is the fastest path to getting a proof of concept out there for them to try (especially if this is time sensitive)?

When faced with the classic triangle of “cheap, good, fast”, it’s widely accepted that you cannot have all three. You have to pick two. But the truth is, low-code solutions are often cheap, fast, and good enough.

If you’re able to slightly lower your standard and be ok with “good enough”, you may actually help the end user more in the long run, whether it’s time to delivery, time to adjust/add new features, or simply having a focus on the “desired future state” instead of the nitty gritty details.

Good enough is just that – good enough.

Just know that it pains me a little bit to write this. I’m a big proponent of “if something is worth doing, it’s worth doing right”. However, I have to accept that MY “right”, is not necessarily THE “right”, and good enough is good enough.

A low-code solution may just be step one.  

The whole idea of low-code is to solve problems quickly. We want to prove the merit of a solution as fast as possible.

Custom code is not likely to do that. Low-code? Far more likely.

Once the ROI has been articulated, where a solution has been created within the limitations of the tool, you start to feel its importance and question how they got by before without it. It gives them a glimpse into a better world and see what is possible.

Odds are, some limitations may need to be pushed past, and it will clearly be worth it to do so with a custom solution. THIS is the time where you get to get your hands into the code and build it the “right” way. But it will be in a world where there is buy-in, and you can focus on making things really great.

Playing devil’s advocate here – if the ROI of going custom isn’t clear after proving it out with low-code, it’s a dang good thing that they didn’t go custom in the first place.

So it can help to look at these low-code solutions as a stepping stone to a custom solution in the future if it’s warranted.

Conclusion

I’ve never really thought about these things in depth before writing this article. I’ve lived them, but never articulated them. I don’t want to paint these mindset shifts in a light that they are easy to do. It has been a long time coming for me, and I still don’t buy it 100% of the time, because there’s nuance to all these things.

But they help me feel a lot more comfortable with the default of “low code first, custom later”.

If you’re a developer going through a similar process, I’d love to hear from you in the comments. Maybe we can wallow together 😉.