Summary: Low-code development tools are seeing an uptick in adoption rates. The problem is, many businesses don’t fully understand low-code before they dive in…which leads to unpleasant surprises and expensive ‘gotchas’. In this article, we explain 10 things you should know about low-code to help minimize these surprises.

Have you ever heard the parable about the blind men who meet an elephant for the first time? Each one of them touches a different part of the elephant and comes away with vastly different ideas as to what an elephant is.

One touched the tail and thought elephants were like snakes. One touched its leg and thought elephants were like trees. It went around like this until all the blind men assumed they knew what an elephant was.

I feel like something similar is going on with low-code software. There’s a growing number of low-code tools. The problem is, they’re all different.

Some are website builders. Others are web app builders. Some require coding. Others are code-free. Some are for simple solutions. Others can build anything.

But, all of these different tools fall under one big “low-code” umbrella.

I’m sure you see where this is going. When someone uses a low-code tool, they come away with the feeling that other low-code tools are similar. But…they’re not. It’s just like the blind man who touched the elephant’s tail and assumed that elephants were similar to snakes.

The bigger issue is that most of the low-code articles you read online make the same mistake. They’re written by people who have used one or two tools or by those who haven’t been in the industry that long. They make sweeping generalizations about low-code software. But, they don’t realize that they’ve just experienced one small part of the big picture.

So, how do you know the big picture before diving into low-code? This is the question I’d like to explore today. In this article, we’ll cover 10 important things to understand before diving into low-code.

1. Know the long-term licensing costs

Before you dive into low-code, understand that comparing licensing fees on an apples-to-apples basis is nearly impossible. Licensing structures and costs vary wildly by vendor.

For instance, here is a short list of common fees you might run across. Vendors might charge based on:

• Number of developers
• Number of end users
• Number of applications created
• Database records
• Applications distributed
• Features used
• Application run-times

Of course, a single vendor won’t charge all of these fees. But, it’s important to know the base licensing model and what factors might lead to more fees.

I always recommend that businesses approach licensing fees from a total cost of ownership standpoint. How much will this cost over 5-10 years? What happens if you add more developers, users, applications, or data? How will that impact the long-term cost?

One hugely important point to remember: The longer you use a low-code platform, the more you come to rely on it. You don’t want to rely on a tool that slowly gets more and more expensive over time.

“This can vary from platform to platform, tools within that platform, and the needs of the business,” says Lindsey Crittendon, Software Engineer at Bravo Consulting Group. “Some low-code platforms require businesses to already have certain services and licenses in place before adding the licensing required for a low-code platform. Depending on the requirements of the project, developers might need access to tools not included in the baseline platform such as premium connectors, additional services provided within the platform, costs associated with a certain number of users, costs associated with a certain number of applications etc. Businesses need to fully understand the pricing model of low-code platforms by understanding their own needs. Is it more beneficial for the business to purchase the platform by user or by application? Does the business need premium capabilities such AI capabilities, premium connectors, multiple environments to separate development and testing from production etc? “

2. Know if the generated applications run independently of the platform

Some low-code tools lock you down more than others…and there are a few different ways that lock-in can happen. One of the biggest ways: Applications that do not run independently of the low-code platform.

In other words, they require an active subscription to run. Or, they’re somehow tied to the development platform. As soon as you stop using the tool, your applications don’t work.

Obviously, you don’t want to set yourself up for that kind of lock-in. You want applications that run independently of the platform. You want apps that run whether or not you’re still using the dev platform.

Robert Mao, Founder of ArcBlock sums it up nicely: “How ‘independent’ will your application built on this low-code tool be? Ideally the low-code implementation can be embedded in the final production or just as a run-time environment, so you have little or no dependency on the original platform. In the future the low-code tool or platform, while dramatically changed or no longer in service, can remain unaffected. Unfortunately, some low code platforms run as a SaaS support layer for the applications, and while this might be the easiest to provide the service, the application built on it, however, will depend on the platform itself.”

3. Understand that low-code doesn’t mean low knowledge or low planning

Some people approach low-code tools as if the software will read their mind. Sure, they do simplify the development process quite a bit, but…they require user effort in a few key areas:

Training
There’s a learning curve with every tool. No getting around that. However, the amount of training needed to become proficient will vary wildly by the software.

“Low-code does not mean low-knowledge,” says David Zhao, Managing Director of Coda Strategy. “They have their own learning curves, which can sometimes be very steep, for the more complex tools.”

Make sure you understand what training options are available for each platform. Some offer basic training documentation to learn on your own while others offer training classes.

My advice: A good training class is imperative if you want to get the most out of your low-code investment. Make sure the vendor offers in-person or virtual training with a platform expert.

Knowledge of your database
In many cases you’ll use a low-code tool over your database tables. While the tool will create applications over that data, it’s still your job to know your database. The better you understand the data in your database, the more successful you’ll be.

Proper planning
While a low-code tool eliminates or reduces the coding aspect, keep one thing in mind: You’re still creating software, and software development requires planning. Low-code doesn’t absolve you from the software development process, it simply eliminates the tedious coding. The planning that goes into building software still applies…even if you’re using low-code tools.

For instance, you must still answer questions like: Where is the data coming from? How will it interact with other applications? Who are the users and how will they use this app? There’s a lot to consider.

4. Understand your employees and how they will use it

Those who are most successful with low-code are those who best understand their employees. Who will use the software? Are they willingly using it, or are they forced? Are they technically inclined?

In my experience, employees who are most successful with low-code have these characteristics:

• They’re at least moderately tech-savvy
• They understand their data
• They’re open to new ways of doing things
• They have ideas about what they want to create with it

That last two points are so important. If your employees already have a wish list of applications they’d like to have and they’re open to learn new things, low-code will help make that a reality. They’ll excitedly use it as they understand the potential problems it will solve.

On the flip side, an employee without ideas as to what they can build isn’t going to go out of their way to use the software. Additionally, employees who approach low-code with negative pre-conceived notions about it will likely not give it a fair shake. Employees must understand how it will help them and be open to new ways of doing things before they truly embrace it.

“Before diving into low-code, I would say, first and foremost, you need to understand how people actually use technology,” says Krishna Rungta, Founder and CEO, Guru99. “I’ve seen many companies that have tried to implement low-code solutions without really understanding how their employees will use it—and it’s often a disaster.. A lot of times, they’ll buy into a low-code solution because they think it’s going to solve all their problems, but then they end up spending a lot of time trying to figure out how to use it properly.”

5. Know the platform’s degree of extensibility & interoperability

Some of the biggest questions surrounding low-code tools revolves around extensibility and interoperability. What does that mean? Here’s a great summary of both:

“Extensibility is determining if the low code tools in current form can’t do something for you, can you still build it yourself, or even extend it by yourself?”, explains Mao. “Interoperability determines how well, or not, a low code-created application will be able to integrate with other components or tools, or the legacy system.”

These are critically important questions to ask before you dive in because they help you understand the tool’s limitations. Let’s quickly look at each one:

Interoperability: I’ll just touch on this as most people already understand the importance of interoperability with existing systems. You must understand if/how a low-code tool will integrate with your existing software/systems before you buy.

Extensibility: This is a little trickier because you’ll often discover specific limitations after using the software for a while. The big question: If you find something that the tool doesn’t do or a feature it doesn’t have, what happens? For many low-code options, the answer is ‘nothing.’ You’re stuck.

Other tools let you add whatever you need–be it a third party tool or custom code. This eliminates most roadblocks you’ll face as you use it.

Additionally, the low-code vendor plays a critically important role in this area. For instance, suppose you run across a feature that you need but isn’t included in the software. How receptive is the vendor to adding that feature to the platform? How open are they to feature requests in general? You’ll find that many low-code vendors will not add features based on customer feedback, but a few will.

My advice: Understand which type of tool (and what type of vendor) you’re choosing…before you invest time or money into it. Otherwise, you’ll discover roadblocks when it’s too late to turn back.

6. Know if you have direct access to code

Photo by Arnold Francisca on Unsplash

Let’s take the last point one step further. Some tools provide access to the underlying application code, while others don’t.

Why does that matter? After all, isn’t the point of low-code to get away from coding?

The truth is, some people will never need to dig into the underlying code. But, having direct access to the underlying code is important for a couple of reasons:

1. It reduces the tool’s limitations: Every piece of software has limitations, and the longer you use that software the more you’ll find. Sometimes, the only way to get around a limitation is at the code level. You probably won’t use that option much, but you’ll be glad you have it if you need it.
2. It opens up customization: What happens if you want to adjust the look and feel to precisely fit your business? Or, what if you want to integrate your apps with a third-party tool? A tool that provides access to the underlying code won’t hold you back. Case in point: Here’s a great example of a company that’s customizing its low-code applications to perfectly fit their business.

“Many low-code tools act as a black box,” says Lucas James, CEO & Co-Founder of AgencyGo. “Developers just have to use the visual development tools and the platform will do the magic itself. The code which make the app work is hidden which can further create problems if something is wrong with the app. Developers feel much more comfortable with tools that provide direct access to the code. So check if the platform you are using makes the code accessible and modifiable or not.”

7. Understand user access permissions

Does everyone in your organization have the same application permissions? Does everyone have access to all of your data? Probably not. That’s why permission control is so important to a low-code platform.

What do I mean by “permission control”? Any enterprise-class low-code platform should let you manage user permissions on a few levels:

Application-level: Application-level permissions let you control application access on a per-user role or per-user basis. This typically includes a role-based menuing system, which displays different menu options to different users based on their role.

Row-level: A critical aspect of B2B, BI, and reporting applications, row-level permissions (or multi-tenant) controls data access within a single application at the row level. Multiple users can access the same application, but only view the data they’re authorized to see.

User privileges: User privilege parameters are used to personalize features and security to individual users or user roles. They can control an application’s look and feel, add or hide user options, limit user capabilities, and more.

“If security is a top priority, choose low-code tools that allow for strict user access permissions that allow teams to choose who has the right to see and edit code,” says Ruben Gamez, Founder and CEO of SignWell. “Look for options with compliance credentials and features like in-platform data encryption, 2FA, SOC2, ISO 27001, and more.”

8. Understand the tool’s interface and how it’s different

There’s no such thing as a ‘standard’ low-code interface. If you look at 10 different tools, you very well might see 10 different interfaces.

Some have an IDE interface. Others take step-by-step approach. Some are point-and-click. Others require a little coding in every build process. Some are geared towards developers while others are geared towards end users.

Which one is best? It all depends on your needs. I highly recommend you set up a demo with the low-code vendor before you buy anything. Let them walk you through the ins and outs of the interface. Once that’s done, try it for yourself. Get started with a trial to see how you like it.

“Before diving into a low-code platform, it’s important to understand the basics of how they work and what they can do,” says Morshed, Founder of Savvy Programmer. “It’s also important to be familiar with the platform’s user interface and how it differs from traditional coding interfaces. Additionally, it’s helpful to have an idea of the types of applications that are best suited for low-code development.”

9. Understand what’s underneath the hood

Of course, the UI is only one part of the puzzle. But, be careful. One of the biggest mistakes you can make is choosing a low-code platform because of the UI. A great UI doesn’t mean it’s a great tool.

“Pretty UI and drag drop tools are low code,” says Mao. “While that may be true, it’s best to evaluate how the low code tools design and engineer the reusability and composability of their modules. Don’t just look at those fancy interfaces!”

The key takeaway: What’s underneath the hood is more important than the UI. How it’s built matters more than how it looks.

Of course, the underlying architecture is often overlooked because it’s invisible to the business users. But, the effects of application architecture are clear as day. Good architecture is more maintainable, scalable, customizable, and better adapts to your business. On the flip side, a poorly built tool will cause endless headaches…even if it looks pretty.

“Some low code tools only provide some wrapping or visual UI for primitive components or building blocks,” says Mao. “While they may include a set of visual and no code tools for basic components like ‘buttons’, ‘checkboxes’, ‘database connections’, ‘data tables’, etc., these still might not provide enough help for building applications, in that there could be limitations on customizability, extensibility etc. Thus, always evaluate the tool based on your requirement, as the best programming tool is the tool that meets the requirement.”

10. Know what the tool is good at…and what it isn’t

I feel like I say this too often, but every low-code tool is different. They don’t all do the same things or have the same features. Some are really good for very specific needs while others are more general.

For instance, some focus on workflow while others offer workflow as part of the larger package. Some include basic reporting features, while others offer more advanced reporting. Some are great at forms, but lack in other areas. I could go on, but I’m sure you get the picture.

The key takeaway: Look for a tool that’s good at many different things. Sure, you might not need them all right now. But, what happens a few years down the road when you need those features? You’ll be glad you have multi-function platform rather than a niche tool.

“Don’t choose a low-code platform that does one thing really well,” says John Li co-founder and CTO of Fig Loans. “Adopting low-code needs to be worth your time and investment, so consider multiple use cases and development needs before you hop into the research and testing phases.

Low-code aims to help you scale faster through accelerated development, so you need a useful tool that aligns with the application and end-user experiences your business creates. Settling on the wrong low-code tool is like buying one really fancy pair of shoes and trying to wear them to a business meeting, the beach, and while running a marathon. You’ll do one thing really well, and everything else will be difficult. Finding the right fit requires considering your needs as you compare low-code features.”

Summary

These are just 10 things to look for before diving into low-code, but the list could certainly be longer. If you would like to add anything to this list, I’d love to hear it. Feel free to share in the comments.