When to use low-code platforms

Low-code platforms offer a startling increase in productivity, and adoption is happening fast. According to recent research from Gartner, 70% of new applications developed by organizations will use low-code or no-code technologies by 2025!

However, 70% is noticeably lower than 100%, so, how do we figure out when to use low-code platforms vs traditional IDE-driven development?

Before running out and trying out the shiny new tools, you need to carefully consider your requirements, because, while there are fantastic benefits to be gained, there are also definite pitfalls.  We’ll help you avoid them.

First, note that this article focuses on how the decision works for people building sophisticated business applications, not people trying to build simpler, consumer-focused applications.

To help you understand if you’re in the right place:

1. If you work at a bank or in finance, at an insurance or pharma company, or manufacturing, or maybe in defense, or at a software vendor targeting such markets, then you are definitely in the right place, and this article will raise and address concerns about low-code that you need to understand.
   
2. If you own a small business or have a concept for one, and you just need a simple app, mostly accessed from people’s smartphones, that just lets people fill in some simple forms and maybe sends you an email or tweets, then you are more in the consumer space. 
   This article likely discusses concerns you don’t have, and we would recommend you take a look at Bubble, which is very consumer-focused.

To organize things, we’ll look at several aspects of the decision as to when to use low-code platforms, including Cost, Data Security, Complexity of Apps, Integration, Customization, and other aspects.

Costs

We’ll start with the money.  Generally speaking, using low-code is relatively inexpensive, especially when you take into account the developer productivity gains.  However, there can be some gotcha situations:

1. Many vendors, including popular ones like Mendix and SalesForce, offer tiered per-end-user pricing based on the features you need.  If your needs are basic, the pricing is great. 
   
   However, you might have a relatively simple app, but need just one feature that places you into the “Enterprise” tier, where costs can be $50 or even $100 per end-user, per month. 
   
   The worst-case scenario here is: you get version 1.0 of your app built, deployed, and working, then for version 2.0, you trip over the need for an “Enterprise” feature. 
   
   This could force a choice between paying 10 times as much vs rewriting your app in another technology
   
2. Some applications that are ripe for low-code may have an enormous user pool. 
   
   For example, you may be trying to automate some business process for HR, and most of the application is meant just for HR staff, but there is one function that might be used just once a year per user – but needs to be available to any employee. 
   
   Suddenly your user pool is 10,000 strong and your costs 500x as large as you thought. 
   
   And, as with ending up in the “Enterprise” pricing tier, it may not occur to you that this could happen until you already have a deployed and working app, and you start on version 2.0.

These risks can potentially be controlled by negotiating upfront to cap costs (if the vendor is willing), or, you can choose a vendor that offers usage-based instead of user-based pricing, such as Reify. 

To sum up: as far as pricing, in considering when to use low-code platforms, you either have to analyze things in advance to be sure you’re never going to have a problem with per-end-user pricing, or you need a platform that doesn’t have gotchas in this area.

Deployment & Private Clouds

When thinking about deployment, first consider, does your organization have a private cloud or a private cloud initiative in progress? 

If so, deployment to a low-code vendor’s cloud is much less appealing: no matter how good their deployment and monitoring features are, it’s still going to be redundant with your private cloud tools, requiring two sets of deployment and monitoring tools to be used.

In considering when to use low-code platforms, having a private cloud initiative may not be a dealbreaker, but you definitely want to coordinate with your private cloud team. You should also look closely at low-code tools that have a deploy-on-your-own or on-premises model (which again includes Reify).

Data Security

Data security issues can be a big influence in deciding when to use low-code platforms.

Are you in a heavily regulated industry such as insurance or defense, having to deal with HIPAA, DFARS, PCI DSS, GLBA, etc? 

Most hosted low-code platforms will deliver a good pitch about how your data is safe with them, and they will explain their security approach in terms of segmentation and firewalls and VPNs, etc., but from long experience, if you are in a highly regulated industry, your IT department is ultimately still going to give you a flat “no”.  

If you are in this situation, you need a solution with an on-premise option, like Reify.

However, if you are not in a heavily regulated industry, my advice would be to grill your prospective vendor and listen to their story. 

Low-code used to be a bit of a “wild west” with little focus on security, but these days most vendors have a pretty good security story, and if a data breach won’t sink your business, you should at least consider the hosted approach. 

Hosted solutions are certainly a much easier option for companies that have only a fledgling IT department.  

Complexity

Low-code is about getting as much done as possible in a visual environment, ideally, using staff who aren’t developers.

Unfortunately, there are lots of apps that would be perfect for a low-code approach, but which have just one screen that you can’t build in the low-code tool.  That problematic screen may have a data-driven UI that depends intricately on what’s in the DB, or it may have complex security rules, or some other problem – there are many possibilities.

In this situation, you have two options:

1. Ask your vendor if they can somehow make it possible to build what you need (via building it for you, a platform extension, hack etc).  Just be aware, the vendor will always say yes, it’s possible.  They aren’t lying to you: given enough resources and time, generally, there’s a solution.
   
   The thing is, the solution is often really complicated and kind of a hack. In the process of solving this one small problem where the low-code platform doesn’t have a good solution, you can easily lose all of the savings you achieved from using low-code in the first place!
   
2. Use Reify: Reify was designed from the ground up to allow low-code to be used for just parts of a larger application. 
   
   Reify screens are neatly encapsulated so they can be plugged into any kind of existing application, with any kind of server technology, or even in “serverless” scenarios. 
   
   This means you can stop worrying about that one screen that may disqualify you from using low-code, because the idea of mixing visually-created screens and hand-coded screens is built right into the platform, at the deepest possible level.

At the moment, we aren’t aware of any other vendors offering this capability, but watch this space: we’re going to be copied!

To sum up, when it comes to application complexity and deciding when to use low-code platforms, you have to either:

1. Carefully analyze the entire application to make sure it won’t go beyond the capabilities of your chosen low-code platform, now or in future versions, or…
   
2. Choose a platform with the Reify architecture, which makes it impossible to get “stuck” and be dependent on the vendor to add something you need.

BPM: a sweet spot for low-code

There are certain classes of applications where low-code is far more suitable, such as BPM (Business Process Management) applications.

BPM applications involve a persistent, multi-party workflow that may take place over days or weeks. 

An example would be passing a CR (Change Request) around multiple departments, to have all the right people see it and approve it (or comment on it and bounce it back a step!). 

Other examples might include approving an expense, officially closing a bug that is supposedly resolved, approving a financial transaction, etc. BPM apps are very common, especially in larger companies that have a formal process for everything.

BPM apps follow such a simple pattern that it would be kind of embarrassing to find a company that was still hand-coding such apps, rather than using the many tools & platforms that are available.

If you need to automate a bunch of pretty basic business processes, there are multiple low-code tools that specialize in BPM (like Pega). Just keep in mind, if you need a UI that goes behind a comment field and “Approve” and “Reject” buttons, BPM-focused low-code platforms can be pretty limited. So, when considering whether to use a low-code platform for BPM, you still have to analyze whether your application is really simple enough that the whole thing fits the classic BPM model (see Complexity above) – you may need a more flexible platform.

Integration 

In approaching the problem of when to use low-code platforms, you may run into problems when integrating with third-party tools, services or platforms.

Low-code platforms offer a variety of built-in integrations with other services, and through iPaaS platforms like Workato, you can typically get many more.

However, when the integration you need just isn’t present, or the platform’s built-in integration doesn’t have the feature you need, what are your options?

Even if you are willing to build your own connector, generally, the low-code vendor can’t just allow you to upload the code for your connector into their cloud (an exception here is Apex from SalesForce, but the pricing is – ouch).

So, in this area, if you are looking to build in the somewhat avante-guarde “serverless” style, where your application is a composite of services offered from various vendors, all stuck together with iPaaS glue, then, you probably don’t need to worry about this point. 

But, if you need to access data behind your firewall, this is another concern that may push you toward an on-premise solution.

Branding / Look & Feel

Branding requirements can often drive the decision of when to use low-code platforms.

Often, companies want a new application to fit neatly into an existing intranet, and blend in nicely in terms of color scheme and UE – or, at the least, not violently clash!

As a baseline, all low-code platforms offer the ability to add a company logo and do basic things like changing the application header to match your corporate colors.

Some vendors, like Appian and Reify, offer quite extensive capabilities in terms of changing color schemes.

However, ultimately, if you need complete control over look & feel, including the ability to get down into the CSS and icons that are built-into the core UI components (like drop-down icons, validation error icons, etc), only Reify has a comprehensive offering in this area: the Skin Editor lets you change most things (very quickly!) and with the on-premise version, you can build a completely custom skin working with CSS/SASS templates and upload it for use in all of your Reify applications.

Summing Up

In making the decision of when to use low-code platforms, there are a bunch of possible “dealbreakers”:

• Pricing: the vendor’s pricing model may not work well if you have lots of users, or if your app is mostly simple but needs just one high-end feature
• Deployment & Data Security: regulations may prevent using some vendors’ deployment platforms, or that deployment platform might be painfully redundant with internal clouds
• Complexity & Integration: you may hit hidden limitations that require a lot of work to get around, or even force starting over with another platform

Unfortunately, avoiding these problems requires doing a lot of analysis up front. It’s easy to get the analysis wrong, or for the analysis to end up wrong even if you did a good job (for example: new requirements, or unstated requirements).

Needing to do all this up-front analysis really goes against the spirit and purpose of low-code: the whole point is to get started quickly!

That’s why we designed Reify to get around all of these problems:

• Our hybrid development architecture means you can use Reify for just the simpler parts of an application. The application can be of any level of complexity, and use any technology you like
• Our on-premise version means you don’t have to worry about cloud security issues, and you can customize whatever you like, without any “gatekeeping” by the vendor
• Our pricing model is predictable and easy to budget for – there are no sudden “cliffs” where expenses increase ten-fold

With Reify, you can confidently and immediately start on any project, whether it’s just one new screen or a whole new application. Imagine being able to use low-code on every project – that’s Reify!

Bonus: software vendors (ISVs) and low-code

For the most part, software vendors (aka ISVs – Independent Software Vendors) have not been using low-code, or if they have, it’s not called low-code (yet). 

There’s a simple reason: most of the time, if you are selling a software product, it’s a rather complicated application, or else no one would bother to buy it! 

Further, if you are looking to deploy to a hosted low-code solution, and offer your solution to multiple customers, you have a multi-tenant on top of a multi-tenant situation. The low-code vendor has to host you and other customers like you, and you need to host multiple of your own customers within your hosted app).

Reify’s flexibility – specifically, the ability to freely mix functionality that was created visually with hand-coded functionality, and of course the ability to control deployment completely – makes it ideal as a base platform for a software vendor.

But there’s a further, extremely powerful possibility: you can bundle Reify itself with your product, so, your software product can be extended with Reify. 

This is a little mind-bending, so let’s take a simple case:

You’ve built a software product, and somewhere, there’s a screen involving some tabs, which was built as a Reify screen.  Because you used Reify to build this screen, you can just add a “Customize…” button that opens that screen in Reify.

From there, users can add their own custom tabs, and then perhaps place a grid and form in that tab and connect them to the data services you exposed to Reify screens, etc – sky is the limit!

Of course, we understand very well that most customers should not be given a free hand to just edit any part of your application – they’ll break it, and you’ll have a support nightmare! 

With Reify, you can easily designate only parts of your UI as editable, or even restrict customization to just adding entirely new UI (new tabs, new screens, new buttons, or whatever your customers want). 

Reify can also offer fine-grained editing: for example, maybe you don’t want your customers to be able to just delete built-in validation logic, but you do want to allow them to add additional validators.

That’s very useful, and Reify can be configured to make that distinction, allowing only safe edits.

Not only is this feasible, we’ve found a way to make it extremely easy to integrate Reify-based extensibility into your application, even if you didn’t start with Reify. 

If you want to learn more about the wild possibilities here, and our vision for hyper-flexible, hyper-extensible applications, take a look at Reify Embedded, and contact us to talk about the specifics of your scenario.