The four cornerstones of no-code lock-in (and how to avoid them)

As enterprises use an increasing amount of no-code software tooling, then it may be reasonable to suggest that the business will become disproportionately reliant upon its handy-but-abstracted software toolset on a number of levels, all of which will increase the chance of lock-in – so how can that pitfall be avoided?


Technology companies always talk about freedom. They love to say that their core go-to-market proposition is built on a foundation of customer choice, freedom to use any selection of their own (or other vendor’s) tools, services and functions, a laissez-faire attitude to whichever implementation partner an organisation wants to select… and a belief in platform-agnostic open source technologies that provide maximum choice, flexibility and control.

In truth, that’s sometimes just showboating.

Although they may promise to travel the open road to interoperability and indeed develop and align most of their platform DNA to be clear and transparent, there’s always an element of ‘we do it better’ that emanates from most tech firms that would rather see customers buy all-in if at all possible.

At its best, this is just a natural desire to win, which can’t necessarily be faulted. At its worst, it amounts to elements and instances of vendor lock-in, where customers find themselves ring-fenced into using a restricted set of IT tools due to the contracts, clauses and customs associated with any given vendor-customer relationship.

Ask any even half-seasoned software or data engineer about this kind of thing and they’ll most likely have already been there, done it and got the t-shirt. We all know that these kinds of scenarios exist, but the rise of low-code and now no-code software platforms is seen by some as an accelerating exacerbator that could make this predicament more common.

The suggestion here is that if an enterprise uses an increasing amount of no-code tooling, then it will become disproportionately reliant upon that abstracted software toolset on a number of levels, all of which will increase the chance of lock-in.

The four no-code lock-ins

If we agree that we can afford an appropriate level of truth to this concept, then what are the four cornerstones of no-code lock-in and how can we look out for their presence and avoid them? They manifest themselves as follows:

  • Lock-in with a no-code vendor’s professional services.
  • Lock-in with the vendor’s custom functionality.  
  • Lock-in at the commercial level.     
  • Lock-in centred on data and code ownership.

Building up a strong internal centre of excellence might be a solution to mitigate against some of these risks here at a wider level, but let’s take our four (above) bulleted cornerstones in turn and examine how to work around them.

Professional services lock-in

A lock-in that results from a vendor’s professional services happens when a business has a limited choice of contractors for its initial system integration and the ongoing implementation of services.

For example, it might be that there’s only one or a handful of integrators in a given region who work with a particular vendor’s solution. In this case, those services might not be easily available upon request and they may not be offered at a competitive price tag.

Founder and CEO of Boston, Massachusetts-headquartered low-code/no-code process management and CRM company Creatio is Katherine Kostereva. Explaining how she built her firm’s technology with an innate and realistic appreciation of the risks in this space, Kostereva recommends selecting vendors who have extensive partnership networks (ranging from global systems integrators to smaller consulting firms) around the world.

Custom functionality lock-in

A lock-in caused by vendor’s custom functionality happens when some specific custom functionality developed by the vendor for a customer is difficult to support, extend or customise. In this case, the business might be able to evolve without requiring constant services from the vendor and its unique expertise.

“What we advise to avoid this and what we generally recommend is to ensure that a low-code/no-code platform offers a modern flexible architecture with maximum composability (such as our own package-based architecture), which enables developers to create loosely coupled blocks of functionality and easily customise them as small chunks, almost independently from one another,” explained Kostereva.

An extensive ecosystem of such composable applications is a true freedom safeguard against a functionality-related vendor lock-in.

Commercial level lock-in

The spectre of commercial lock-in often arises as a result of complex or non-transparent contracts, terms of use and hidden costs. It happens when the initial total cost of ownership increases over time due to the inability to work without paid extra modules and integrations, progressively increasing data usage fees and other creeping costs hidden in the contract.

To combat this, Kostereva and team say that it is important to check how transparent contract clauses are right from the start. This is especially true for no-code platforms because they often come as part of sophisticated vendor ecosystems.

“The solution to this issue is transparency, diligent study of the contract, and genuine care. For us, ‘genuine care’ is a part of our company’s DNA. By that term we mean building sincere and long-lasting relationships, providing a helping hand first (and then thinking about business and costs afterwards), communicating openly and transparently and bringing value,” said Creatio’s Kostereva.

Data & code ownership lock-in

Finally (for now), let’s consider data and code ownership lock-in. This happens when there is no simple way for the user (by which we initially mean developers, but also now the low-code/no-code business community) to access, modify, or transfer their custom code and data upon termination of relationships with the vendor.

“All these options are a must-have for modern no-code platforms and should be explicitly listed in the contract. From the technical side, we provisioned this capability with our flexible package-based architecture and use of modern technology. The user customisations are stored in separate packages, which the user can easily access, modify and download. The user data is fully protected and can be accessed in any way by the owner at any time,” asserted Kostereva.

Kostereva recommends no-code solutions that use popular technologies and programming languages (C#, JavaScript, Angular). In Creatio’s case, this makes reusing the source code generated by Creatio no-code tools quite easy for professional developers, if the need may be.

Mushrooming popularisation

As the universe of ready-to-use apps now starts to mushroom and the popularisation of low-code/no-code continues to expand unabated, perhaps we should develop a new mental technological checking mechanism to check for these lock-in pitfalls.

Without wishing to stymie, thwart or attenuate the benefits of lesser-code platforms and tools, their impact could be a channel for reduced freedom if we fail to look out for some of the caveats and cautions tabled here.

Let’s remember, low-code less so but particularly no-code tools promise to give organisations a chance to automate enterprise workflows with no special skills. If a business wants to achieve those levels of self-sufficiency, then it must approach these platforms with due care and consideration to reap the rewards that can be reaped.