Summary: A growing trend, low-code development claims to address many of the common challenges facing businesses today. But, how do you choose the best platform for your business? How can you avoid surprises or “gotchas” when selecting a tool? In this article, we explore 9 questions to ask before choosing a low-code tool.

Low-code development is on the rise. According to Forrester, the low-code development platform market will grow by about 50% this year.

Yet, despite its rapid growth, low-code tools are still surrounded with confusion. We see this confusion around a few different areas:

A. Confusion about how low-code differs from development tools of the past
Low-code development promises fast web application development with almost no hand-coding. This isn’t a new concept. It started with the 4GL tools of the 70s, 80s and 90s and grew into Rapid Application Development (RAD) tools.

The problem: Those who used 4GL and RAD tools assume that low-code is the same thing. They assume that the drawbacks found in the old tools exist in low-code tools.

In reality, low-code tools are different platforms entirely. Sure, they promise similar benefits. But, software has advanced dramatically since RAD tools were popular. Low-code offers more capabilities and fewer drawbacks than their predecessors.

B. Confusion about low-code’s definition
From what I’ve seen, many business leaders don’t even fully understand the trend. If you ask 10 people to define low-code, you might get 10 different answers.

What is low-code? I won’t get into all of it here, but it’s covered in more detail in this article: Low-code development 101: Understanding the basics.

C. Confusion created by software vendors
“Low-code” software is all over the board. Due to the lack of agreement on low-code’s definition, we’re seeing many “low-code” platforms enter the market that aren’t exactly low-code.

Some vendors see low-code as a chance to jump in on a trend. Their software might offer some low-code capabilities, so they rebrand it as a “low-code tool.”

This creates a problem for those looking for low-code software. They find that comparing options is like comparing apples and oranges.

If you’re looking for the best low-code platform, what should you look for? What hidden “gotchas” or drawbacks should you avoid? Today, let’s explore a few questions to ask before you choose a low-code tool.

1. Will we get locked into this low-code platform?

It’s the first question you should ask. What happens if we decide to move away from this platform?

To answer that question, you must look at the software from a few different angles:

1. Who controls the data? Is it stored in-house or on their servers? If it’s stored on their servers, ensure there’s a simple way to export and download that data if necessary.

2. Does the platform create standalone applications, or do they require an active subscription to run? Obviously, you want applications that run independently of the development tool. That way, they’ll still work if you move away from it.

3. What type of code does it generate? Does the tool generate proprietary code or open-source code? Is the code messy, or clean? Can it be maintained manually if necessary?

“How much vendor lock-in will occur by using this tool?,” asks Chris Shellenbarger, Founder of CloudRepo. “Will I be able to easily export my data into another tool if we decide to switch down the road? Is the tool based on open source software or is it completely proprietary?”

“What you’re concerned about with any questions related to lock in is what will happen when you want to switch off of this tool to another? What if the vendor goes out of business? What will you do in these cases? A good example is GitHub vs BitBucket – these are both based on the open-source project Git – switching between the two requires minimal effort and so the lock-in risk is very low. An example of extremely high lock-in would be if you used a tool which stored its information in a proprietary format that only its software could read – switching would be very difficult.”

2. What kinds of apps will you be building?

As I touched on above, not all low-code platforms are created equal. Some have a very specific focus, while others let you create a wide variety of enterprise applications.

“Different low-code tools have different specialties,” says Jason Bloomberg, President, Intellyx. “Some are best at building mobile apps. Others focus on workflow-centric applications, while a third category centers on data-related problems. You should understand the problems your apps will address before selecting the right tool.”

One tip: Look past your current project/need when selecting a tool. Sure, you might need mobile app development now, so a mobile-focused tool would make sense. But, what happens when you need workflow applications or reports? What if you need BI and dashboard applications? Do you go buy another tool? In my experience, software that can solve multiple challenges makes for a far better long-term investment.

3. What type of fees does the vendor charge?

Don’t assume that all licensing structures are created equal. Some appear inexpensive upfront but surprise you with a bunch of fees as you use it. Here are some of the common fees to ask about:

Developer seat fees: These fees are charged based on the number of people who will be building apps with the platform.

End-user seats: These fees are charged based on how many people are using the applications created by the developers.

Run-time fees: While I don’t see run-time fees that often anymore, it’s something to watch for. These are fees that occur every time the generated applications are run.

Distribution fees: This is an important point to consider if you plan to distribute or sell the generated applications. Many vendors charge a distribution fee per application, which can get expensive quickly.

Maintenance fees: Is maintenance and support included in the license fees, or is that an extra charge? If they charge a maintenance fee, understand what’s included in the plan. Ideally, any good maintenance plan will include expert support and all product enhancements.

4. How do you handle security?

When selecting a low-code tool, examine security in two separate areas: Internal security and external security. Let me explain:

Internal security: From an internal standpoint, you can’t give users unlimited access to your data. Does the platform let your IT department control the data and user access? Does it let you secure data by user or user role? Each user should only have access to the data and features that they require.

External security: From an external standpoint, how secure are the generated applications? As explained below, you should ask a few important questions.

“Every vendor today will make claims about the company’s security – it’s important for a business leader to ask several key questions to get a better understanding of how security is implemented,” says Shellenbarger. “How are passwords stored? Naive security implementations will store passwords in plaintext and will expose all passwords if compromised. At a minimum, passwords should be hashed so that the passwords can not be determined even if the hashes are discovered. Dropbox provides an excellent combination of multiple hashes plus encryption to protect your passwords.

What encryption algorithms and implementations are being used? This is important because you want to ensure that the company is using a well known, widely used, open-source implementation of encryption and hashing libraries. If someone has implemented their own cryptography library (and worse, kept it proprietary) then this is a red flag. The best security algorithms are public and open source because the protection lies in the secrecy of the keys rather than the algorithm.”

5. How do you use the product internally?

By definition, low-code software simplifies development. Any organization that develops web applications and/or software would benefit from it. That should include the low-code vendor themselves. As explained below, this is something you should ask about.

“Ask the vendor if they use their own product internally,” says E. Scott Menter, VP Business Solutions, BP Logix. “If so, in what ways?”

It’s an interesting question to ask, and one that the vendor probably doesn’t hear very often. But, it sheds some light on how the vendor sees their software. Do they even use internally? Do they only use it for specific needs, or do they use it for everything?

6. How do you handle support?

Customer support is an important, yet often overlooked consideration. It can make or break software, but it’s rarely discussed before the purchase.

“Is support included with the license?,” asks Menter. “If so, is there a limit on the number of support tickets/requests? Is support performed by your company, or do you use a third party?”

In my experience, you’ll find that vendors handle support in one of three ways:

Outsourced: Some software vendors still outsource their support overseas or to another company. Generally speaking, you’ll find this approach delivers frustration and inferior service.

Internal, tiered support: Tiered support starts you off with a low-level support employee, with basic knowledge of the product. If they can’t answer your question, it gets passed up the ladder.

Internal, expert support: This approach ensures that you’re speaking with a product expert every time you have a question/issue.

Make sure you understand which option the vendor uses before you buy. Customer support plays a major role in the product’s success within your company.

7. Can you customize the generated applications or include custom business logic?

Customization (or a lack thereof) is a big concern with development tools in general. Many assume that you can’t customize the generated business applications. They believe that you’re stuck with whatever the platform creates.

These beliefs stem from the myth that low-code platforms are the same as code development tools of the past. In the past, customization was limited. These days, most enterprise-class won’t have those restrictions.

To be sure you choose a tool that doesn’t limit your options, ask questions like:

– How do you customize the generated applications? Does the tool include a graphical editor? Does it let you modify the HTML/CSS if necessary?
– Do you allow white-labeling? Can you customize the output to match your company’s look and feel?
– Can we add custom business logic when we build applications? Is there a way to add external code to the applications? Can we create rules/logic so the applications fit our business processes?
– Can you create/modify application templates? This is important because it lets you customize the look/feel of every generated application without manually changing each one.

8. What skills are needed by employees of my company to use the platform?

The business case for low-code software usually boils down to time and money savings. They let you deliver applications in less time, using fewer resources. They reduce the need for coding knowledge in the development process.

However, these benefits only apply if the platform has a low learning curve and doesn’t require additional technical skills.

The question: What skills are needed to use the platform? How long will it take to get up and running? What technical knowledge will our developers (or citizen developers) need? These are all important questions to consider when calculating the ROI of the software.

“Typically the reason you want to use a low-code platform is so that you can reduce the cost of developing the project or product,” says Raji Sankar from PoC IT Online. “A project or product typically requires business analysts, technical architects, developers and QA in varying numbers, based on the platform chosen. technical architects are very highly paid. If you can cut down the number of technical analyst and developers, the cost goes down. If you need to have a technical architect anyways, whether you use a low-code platform or not, then the cost does not go down too much. You may in-fact end up paying a lot because of the architects involved.”

9. How will it integrate with our existing systems?

Chances are, you don’t want to create apps that operate independently of your existing systems. Integration is a critical part of any low-code tool.

“Every product requires integration to existing systems currently since computerization has touched almost everything,” says Sankar. “Trying to develop an independent isolated product or project is not possible in the current market, hence integration is a huge part.”

Here are a few important questions to consider:
– Does the software offer read/write capabilities, or is it read-only?
– What types of data sources does it connect with?
– How will it integrate with our existing software and systems?

Summary

These are just a few questions to ask about low-code platforms, but the list could be much longer. Would you add anything to this list? Feel free to comment below!