According to our research, the top four fears that discourage organizations from adopting low-code are lack of flexibility, vendor lock-in, security, and scalability. In this five-article series, we’ll dig into these myths and attempt to shine a light on the realities. This, the second in the series, looks at the fear of vendor lock-in.

The Research

Over 3,500 IT professionals took part in this year’s State of Application Development Survey. Thirty-four percent of respondents said they were already using a low-code platform, and another nine percent said their organization had plans to start using one soon. We asked the remaining 57 percent of respondents what discouraged their organization from adopting low-code. The chart below summarizes what they said.

The Reasons for Not Using or Considering Low-Code

Reasons for Not Using Low-Code

If your organization is not yet using low-code, hopefully, you’re well on the way to addressing the top item on this list, (lack of knowledge). After just a couple of hours spent researching the OutSystems website, you will not be able to blame a knowledge shortfall as a reason for inaction.

You can learn from detailed demos, customer case studies, and delve into the technical details and evaluation guide. You can even spin-up your own OutSystems Personal Edition for free and immerse yourself in our comprehensive video tutorials.

Altruistic? Yes. However, this is the way low-code was always meant to be.

“... available to customers at low- or no-cost in money and training to begin, with costs rising in proportion to the business value received…”
Forrester’s original low-code platform definition, 2014

The Top Four Fears of Low-Code

Having put lack of knowledge to one side, I thought it would be helpful to delve into the top four fears that leave non-adopters standing on the sidelines, and offer some proof-points and counter-arguments that might provoke a rethink.

Nineteen percent of respondents said they didn’t believe they could build the types of app they need with low-code.

The first article in this series “What Can You Build With Low-Code?” provides a detailed riposte, including;

  • Details about the kinds of low-code apps delivered, according to respondents of the survey mentioned above
  • Links to three common use cases that include example apps and case studies
  • A variety of out-of-the-ordinary examples of low-code apps, involving IOT, blockchain, machine learning, and AI

With respect to low-code use cases, this post has it all—from cruisy blue runs to adventurous off-piste expeditions. (Excuse the skiing analogy.)

The Fear of Vendor Lock-in

Sixteen percent of respondents cited concern about vendor lock-in as a reason their organization was holding back from adopting low-code. The remainder of this article is devoted to this topic.

First, a definition of vendor lock-in, kindly provided by Wikipedia.

In economics, vendor lock-in (also known as proprietary lock-in or customer lock-in) makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs.

From my perspective, three main risks could lead to vendor lock-in. These are:

  1. Your dependency on vendor-supplied customizations when requirements cannot be met using “out-of-the-box” capabilities.
  2. Your dependency on vendor-supplied professional services to deliver solutions.
  3. Your dependency on a licensed, proprietary vendor technology to run the applications you have built.

Let’s take a more in-depth look at each of these flavors of lock-in.

Dependency on vendor-supplied customization

In the past, I worked for a small low-code vendor, so I know that reality and marketing claims can be considerably different. In this past life, integration was our Achilles’ heel. Although we claimed to offer SOAP and REST API integration for any foreign system, the reality was we just had a few examples that we’d show in sales demos. If customers needed anything that wasn’t on that short list, we’d develop the integration and deliver in-project with professional services.

It was difficult for customers to achieve self-sufficiency. On any project, they were likely to uncover requirements that the out-of-the-box platform could not handle. Custom capabilities were then shoehorned into the customer’s platform build. In some cases, where such customization was out of alignment with our product evolution, future platform upgrades would entail significant consulting effort. This led not only to vendor lock-in but version freeze as well.

Professional services revenue is often a mainstay of smaller low-code vendors.

By asking the right questions, you can identify these risks during the purchasing process. Ask for an exact list of the prebuilt integration connectors. Find out how you can build your own REST, SOAP, or other kind of integration using out-of-the-box capabilities.

In addition, Forrester and Gartner evaluate low-code vendors. You can get free access to their reports here. (Gartner uses the term High Productivity Application Platforms as a Service, abbreviated hpaPaaS.)

Both rank low-code vendors more highly if they provide comprehensive capabilities for extending platform capabilities with custom code or scripting.


“Does the vendor provide declarative tooling customers can use to add UX controls, new integration adapters, and any other custom platform elements?”
An evaluation criterion from Forrester’s Wave™ Low-Code Development Platforms for AD&D Pros


“Low-code vendors should provide a scripting or fourth-generation language (4GL) programming environment… Many hpaPaaS solutions also support pro-code extensions using JavaScript or 3GL languages.”
An evaluation criterion from Gartner’s Magic Quadrant for Enterprise High-Productivity Application Platforms as a Service

Paying attention to the above evaluation criteria will help you avoid becoming reliant on customizations only your vendor can provide, and thereby reduce the risk of lock-in.

Dependency on vendor—or consultant-supplied professional services

At first glance, this may seem like the same issue discussed above. Admittedly, the outcome is the same. However, the causes are entirely different. Instead of product capability gaps leading to vendor lock-in, this is a question of customers being unable to achieve self-sufficiency because of a wide variety of softer issues. For example:

  • Self-study training materials and documentation are lacking.
  • Support communities and forums are inadequate.
  • The prevalence of undocumented features that only the vendor knows about.
  • The lack of expert partners, app store, and companion products.

Low-code is still quite a young software category, with a significant number of new entrants in the past four years. Only market leaders tend to have the resources and time to solve the kinds of issues we’re talking about. Whether you call this “ability to execute,” or “completeness of product,” the vendors in leadership positions in the analyst reports mentioned above are most likely to have in place what it takes to make clients self-sufficient.

Here’s a quick run-down on how OutSystems helps clients succeed, without dependency on our professional services organization.

  • The OutSystems Personal Environment and comprehensive self-study training and documentation provide everything new developers need to get started with OutSystems.
  • Our thriving developer community has over hundreds of thousands of members who collaborate to answer others’ questions. We provide a free support knowledge base and paid support options.
  • Our product is proven and high-quality. OutSystems was founded in 2001, so we’ve had 17 years to improve our low-code platform. The recent $360 million investment from KKR and Goldman Sachs equips OutSystems to stay ahead of the market with the best and most innovative low-code platform. This post from Paulo Rosado, OutSystems Founder and CEO, explains how this investment is being put to work for the benefit of our customers.
  • Our global network of 250 partners ranges from multinational system integrators to boutique local and industry consulting partners. If you need additional resources or advice, you’re certainly not locked-in to just one supplier.
  • The OutSystems Forge provides a repository of over 1,100 reusable application modules, components, connectors, widgets, themes, and sample code that speed up application delivery. Resources like these avoid the risk of lock-in and ensure you don’t reinvent the wheel when prebuilt functionality is available.

Dependency on licensed, proprietary vendor technology

The two previous reasons for lock-in could apply to most (perhaps all) software genres. However, the risk of tying your organization to a dependency on licensed, proprietary vendor technology is something quite specific to low-code.

All low-code, and indeed no-code, platform vendors promise faster and simpler ways to build applications. However, building is just a fraction of the full software lifecycle.

For a moment, let’s focus on the question of what customers have to license, and keep paying for, to run the applications they have built.

This is something that industry analyst Jason Bloomberg of Intellyx explored in his excellent Forbes article “Low-Code/No-Code? hpaPaaS? Here's What Everybody Is Missing.” Although this is well worth reading to hear Gartner’s hpaPaaS categorization compared to “an elephant sitting on a flower,” the main thrust of the article contrasts two different approaches that various low-code platforms use for execution:

  • Code-generation platforms output executable code that can be installed on a variety of standard infrastructures. OutSystems is one such platform.
  • Model-driven execution platforms host the application in such a way that the platform interprets and executes the model directly at runtime.

If vendor lock-in is your fear, the need to interpret the model at runtime probably gives you the collywobbles. If you stop licensing and paying for the platform, you’ll no longer have access to the proprietary technology that makes your app run. That’s curtains for your applications. Your exit options are perhaps limited to raw data exports and some static documentation.

"If vendor lock-in has a sliding scale from “grabbed by the short and curlies” to “entrapped with padded handcuffs,” the need for a licensed runtime interpreter is very much at the less comfortable end of that scale."

As befits an analyst, Jason Bloomberg’s article cites plusses and minuses for both genres of low-code platform. However, several of the advantages he describes for code-generation might seem compelling to you:

  • The ability to create native mobile apps
  • The ability to create apps that work when disconnected from the internet
  • The likelihood that apps perform better compared to those that require runtime interpretation
  • The ability to continue using deployed apps even if the vendor disappeared

Naturally, many users of low-code want nothing to do with the deployment of code and infrastructure management. That’s certainly true if your intended developers are outside of IT.

That said, a capable low-code platform like OutSystems includes strong DevOps capabilities such as single-click unbreakable deployment and a full range of deployment options including cloud, hybrid, and on-premises.

"It seems you can have your cake and eat it."

OutSystems Standard Architecture With No Lock-in

The fear of lock-in is such a common concern when companies are researching low-code that we’ve provided chapter and verse in our Evaluation Guide.

"OutSystems takes your application models and generates standard and optimized applications that are ready to run on a standard web farm or cloud architecture. Once generated, applications can run independently of any OutSystems components, and all of your application data remains under your control and accessible with standard tools."

However, although being able to disengage from a vendor in this way is a reassurance at the start of a relationship, it is shortsighted to predicate your whole purchase decision on such freedom.

Don’t Lose Sight of The Low-Code Agility Advantage

The whole value proposition for a platform such as OutSystems is the ability, not just to develop faster, but to make the entire applications delivery process more agile.

Your organization’s ability to stay competitive depends not on deploying static apps that will never change, but on achieving the ability to innovate continuously and adapt systems and business models to meet the ever-changing needs of your customers.

This is where the right low-code platform earns its keep. In reality, whichever low-code platform you choose, cutting adrift apps from the originating low-code platform is not a recipe for continued agility.

The tradeoffs between freedom and the constraints that come alongside automation and improved efficiency is a balancing act that IT leaders have been performing for years. Technology leaders have long invested in automation to squeeze time and costs from the software delivery lifecycle.

Vendor lock-in
Total Application Delivery Time

They’ve already invested in infrastructure as a service (IaaS), to automate the provision of new servers in the cloud.

They’ve invested in platform as a service (PaaS) to give developers everything necessary to start coding automatically without delay. 

They’ve invested in DevOps tools to automate and significantly speed up the process of pushing new code to production.

But now it’s time to apply automation to App Development, the longest, most costly, and riskiest part of the software development lifecycle. Not to do so leaves a bottleneck in the software production line that many organizations are trying so hard to optimize.

Customers or Hostages?

I hope the arguments I’ve put forth have thrown some light on three kinds of lock-in and the risks that can give rise to them. At the same time I’ve attempted to lay out some rational reasons why, with OutSystems, you’re more likely to feel like a customer than a hostage.

All technology choices come with restraints in one way or another. It’s a question of degree. However, as you can find out from these hundreds of independent peer reviews, our prisoners seem to be peculiarly happy.

More Reading on Low-Code Myths

Myth # 1 – We cannot build what we need. Read What Can You Build With Low-Code?

Myth # 3 – Low-Code is insecure.

Myth # 4 – Low-Code will not scale.

Myth # 5 – Low-Code will be bad for my career.


Want to know more about the myths and realities of low-code? Check out our webinar.