What is low-code vendor lock-in?

Low-code vendor lock-in is the loss of practical ability to leave a platform after applications are built on it. It usually comes from a combination of proprietary runtime requirements, proprietary data schemas, non-portable code exports, and pricing that scales with usage. Most low-code vendors do not call this lock-in, but the buyer experiences it as such on renewal.

How do I evaluate a low-code platform for lock-in risk?

Ask the vendor five specific questions. Where does my data physically live? Whose database schema runs my applications? Can I export the source code I built, in a usable format? If I stop paying tomorrow, do my running applications keep working? Is the price predictable across the next five years? The honest answers to those five questions tell you what walking away would actually cost.

Why does on-premise low-code reduce vendor lock-in?

On-premise low-code platforms run the generated applications on servers the customer controls, against databases the customer owns. The vendor's involvement is in the build tooling, not in the runtime that serves users. The applications continue to work even if the vendor relationship ends, which is the practical definition of avoiding lock-in.

Is a perpetual license low-code platform better than SaaS low-code?

For lock-in risk, yes. A perpetual license decouples the right to keep running what you have already built from the obligation to keep paying. SaaS low-code platforms tie the runtime to the subscription, which means the cost of leaving is the cost of rebuilding. Perpetual licensing eliminates that specific risk. SaaS may still be the right choice for some teams, but the tradeoff should be understood up front.

Does m-Power lock customers in?

m-Power generates standard application code that runs on customer-controlled infrastructure, reads and writes to customer-owned databases, and continues to function if maintenance lapses. The license is a one-time fee. The applications a customer builds are not tied to mrc's continued operation. By the criteria above, m-Power is built specifically to avoid the lock-in patterns common in low-code SaaS.

May 2026 – mrc's Cup of Joe Blog

The Low-Code Vendor Lock-In Test: Five Questions Before You Sign

By Sal Stangarone / Low-code

One of the most common myths I’ve heard about low-code vendor lock-in is that it’s unavoidable. Pick any platform, the thinking goes, and you’ll be locked in within three years. That’s just part of the deal.

The only problem with that assumption: It’s wrong.

Of course, lock-in is real and exists across many low-code platforms. But it isn’t built into low-code as a category. It’s built into how a specific platform is architected. Some platforms create it. Others don’t. The trouble is that the difference is hard to see during a demo, when every vendor sounds open.

The bigger problem is, a vendor may not define “lock-in” the same way you do. The contractual definition (no clause prevents you from leaving) and the operational definition (the cost of actually leaving) are not the same thing. The architectural decisions baked into a platform are what really determine lock-in, and they are the part that doesn’t usually come up in a sales conversation.

Rather than asking about vendor lock-in, the better question is this: If you wanted to take your applications, your data, and your team and walk away, what specifically would break?

Of course, you can’t ask that question outright in a sales call. The vendor doesn’t know the answer in the abstract any more than you do. But you can answer it yourself, by working through five smaller questions. Each one tests something structural about how a low-code platform works that goes beyond what marketing and sales say about it.

Run any platform on your shortlist through these questions, and the answers will tell you exactly what leaving would cost.

The first one is the foundation. Everything else depends on the answer.

…

The Low-Code Vendor Lock-In Test: Five Questions Before You SignRead More »

Coming in May: Build AI Agents in Your Environment, Governed by Your Own IT Team

By Sal Stangarone / AI Agents, Artificial Intelligence

In speaking with IT leaders recently, I keep hearing the same thing. Employees are using AI, with or without IT’s blessing.

The problem: They’re using it in risky ways. For example:

They’re pasting customer lists into ChatGPT to summarize them.
They’re feeding contracts into public chatbots to analyze them.
They’re asking AI tools to review company data they exported to a spreadsheet.

Here’s the part that should worry you. Studies keep finding the same thing, including IBM’s 2025 Cost of a Data Breach report: Employees routinely ignore the AI tools their company actually paid for. Why? Because the sanctioned tools are slower, harder to get into, or don’t do what they need. So, they reach for the public ones instead.

In short, Shadow AI is becoming the default.

I talk to IT leaders who feel like they’re in an impossible spot. They’re trying to manage a workforce that’s already using AI, on tools they didn’t approve, against data they’re responsible for, in ways their auditors and privacy team can’t see. Policy memos don’t fix that.

The only thing that fixes it is giving people a sanctioned path that’s easier than the rogue one. IT needs a way to deliver sanctioned AI that’s easy for the users…without giving up control.

That’s exactly what’s coming next in m-Power.

…

Coming in May: Build AI Agents in Your Environment, Governed by Your Own IT TeamRead More »

Month: May 2026