{"id":15546,"date":"2026-05-27T12:24:53","date_gmt":"2026-05-27T17:24:53","guid":{"rendered":"https:\/\/www.mrc-productivity.com\/blog\/?p=15546"},"modified":"2026-05-27T12:45:04","modified_gmt":"2026-05-27T17:45:04","slug":"the-low-code-vendor-lock-in-test-five-questions-before-you-sign","status":"publish","type":"post","link":"https:\/\/www.mrc-productivity.com\/blog\/2026\/05\/the-low-code-vendor-lock-in-test-five-questions-before-you-sign\/","title":{"rendered":"The Low-Code Vendor Lock-In Test: Five Questions Before You Sign"},"content":{"rendered":"\n<!-- Structured Data for \"Low-Code Vendor Lock-In Test\" Blog Post -->\n<script type=\"application\/ld+json\">\n{\n  \"@context\": \"https:\/\/schema.org\",\n  \"@type\": \"BlogPosting\",\n  \"headline\": \"The Low-Code Vendor Lock-In Test: Five Questions Before You Sign\",\n  \"description\": \"Low-code vendor lock-in is rarely a contract clause. It is an architecture decision. Five questions to test any platform before you sign the renewal.\",\n  \"author\": {\n    \"@type\": \"Person\",\n    \"name\": \"Sal Stangarone\"\n  },\n  \"datePublished\": \"2026-05-27\",\n  \"dateModified\": \"2026-05-27\",\n  \"image\": \"https:\/\/d4ey5ve3eb27c.cloudfront.net\/img\/blog\/vendor-lock-in.png\",\n  \"publisher\": {\n    \"@type\": \"Organization\",\n    \"name\": \"mrc\",\n    \"logo\": {\n      \"@type\": \"ImageObject\",\n      \"url\": \"https:\/\/d4ey5ve3eb27c.cloudfront.net\/img\/mrc-logo-dark.png\"\n    }\n  },\n  \"mainEntityOfPage\": {\n    \"@type\": \"WebPage\",\n    \"@id\": \"https:\/\/www.mrc-productivity.com\/blog\/2026\/05\/the-low-code-vendor-lock-in-test-five-questions-before-you-sign\/\"\n  }\n}\n<\/script>\n\n<!-- Breadcrumb Schema -->\n<script type=\"application\/ld+json\">\n{\n  \"@context\": \"https:\/\/schema.org\",\n  \"@type\": \"BreadcrumbList\",\n  \"itemListElement\": [\n    {\n      \"@type\": \"ListItem\",\n      \"position\": 1,\n      \"name\": \"Home\",\n      \"item\": \"https:\/\/www.mrc-productivity.com\/\"\n    },\n    {\n      \"@type\": \"ListItem\",\n      \"position\": 2,\n      \"name\": \"Blog\",\n      \"item\": \"https:\/\/www.mrc-productivity.com\/blog\/\"\n    },\n    {\n      \"@type\": \"ListItem\",\n      \"position\": 3,\n      \"name\": \"The Low-Code Vendor Lock-In Test: Five Questions Before You Sign\",\n      \"item\": \"https:\/\/www.mrc-productivity.com\/blog\/2026\/05\/the-low-code-vendor-lock-in-test-five-questions-before-you-sign\/\"\n    }\n  ]\n}\n<\/script>\n\n<!-- FAQ Schema -->\n<script type=\"application\/ld+json\">\n{\n  \"@context\": \"https:\/\/schema.org\",\n  \"@type\": \"FAQPage\",\n  \"mainEntity\": [\n    {\n      \"@type\": \"Question\",\n      \"name\": \"What is low-code vendor lock-in?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"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.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"How do I evaluate a low-code platform for lock-in risk?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"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.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Why does on-premise low-code reduce vendor lock-in?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"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.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Is a perpetual license low-code platform better than SaaS low-code?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"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.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"Does m-Power lock customers in?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"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.\"\n      }\n    }\n  ]\n}\n<\/script>\n\n<!-- HowTo Schema -->\n<script type=\"application\/ld+json\">\n{\n  \"@context\": \"https:\/\/schema.org\",\n  \"@type\": \"HowTo\",\n  \"name\": \"How to Test a Low-Code Platform for Vendor Lock-In\",\n  \"description\": \"A five-question framework for evaluating any low-code development platform for the practical cost of leaving, before signing the contract.\",\n  \"step\": [\n    {\n      \"@type\": \"HowToStep\",\n      \"position\": 1,\n      \"name\": \"Determine where your data physically lives\",\n      \"text\": \"Identify whether the data your applications create and read sits in the vendor's cloud, in your cloud but in a vendor-managed database, or in your existing environment under your control. Only the third option keeps the data layer in your hands.\"\n    },\n    {\n      \"@type\": \"HowToStep\",\n      \"position\": 2,\n      \"name\": \"Identify whose database schema runs your applications\",\n      \"text\": \"Ask whether your applications run against a vendor-generated schema optimized for the vendor's runtime, or against your existing database schema designed by your team. A vendor-owned schema becomes a permanent dependency.\"\n    },\n    {\n      \"@type\": \"HowToStep\",\n      \"position\": 3,\n      \"name\": \"Test whether you can edit and export the source code\",\n      \"text\": \"Confirm that the platform produces compilable source code in a public language like Java, PHP, or .NET that your developers can read, maintain, and run without the vendor. Proprietary configuration files and metadata snapshots are not portable exports.\"\n    },\n    {\n      \"@type\": \"HowToStep\",\n      \"position\": 4,\n      \"name\": \"Verify your applications keep running if you stop paying\",\n      \"text\": \"Ask whether the applications you have already built will continue serving users after the contract ends. If the runtime is licensed and required, your applications stop the moment payment stops. A platform that generates standalone code on infrastructure you control passes this test.\"\n    },\n    {\n      \"@type\": \"HowToStep\",\n      \"position\": 5,\n      \"name\": \"Calculate the five-year price, not the year-one discount\",\n      \"text\": \"Project usage at year three and year five based on how your team adopts tools. Multiply against the platform's per-user, per-app, or per-transaction meter. The total is what you are signing up for. A one-time perpetual license or flat annual fee removes this variable entirely.\"\n    }\n  ]\n}\n<\/script>\n\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/d4ey5ve3eb27c.cloudfront.net\/img\/blog\/vendor-lock-in.png\" alt=\"\"\/><\/figure>\n\n\n\n<aside style=\"border:1px solid #d0d7de;border-radius:6px;padding:20px 24px;margin:0 0 32px 0;background:#fafbfc;\">\n  <div style=\"font-size:11px;font-weight:600;letter-spacing:1.5px;color:#666;text-transform:uppercase;margin-bottom:8px;\">Definition<\/div>\n  <div style=\"font-size:20px;font-weight:600;color:#1a1a1a;margin-bottom:10px;\">Low-code vendor lock-in<\/div>\n  <div style=\"font-size:16px;line-height:1.55;color:#333;\">The practical inability to leave a platform after building applications on it. Caused by proprietary runtimes, vendor-owned database schemas, non-portable code exports, and usage-based pricing (not by contractual restrictions).<\/div>\n<\/aside>\n\n\n\n\n<p>One of the most common myths I&#8217;ve heard about low-code vendor lock-in is that it&#8217;s unavoidable. Pick any platform, the thinking goes, and you&#8217;ll be locked in within three years. That&#8217;s just part of the deal. <\/p>\n\n\n\n<p>The only problem with that assumption: It&#8217;s wrong.<\/p>\n\n\n\n<p>Of course, lock-in is real and exists across many low-code platforms. But it isn&#8217;t built into low-code as a category. It&#8217;s built into how a specific platform is architected. Some platforms create it. Others don&#8217;t. The trouble is that the difference is hard to see during a demo, when every vendor sounds open. <\/p>\n\n\n\n<p>The bigger problem is, a vendor may not define &#8220;lock-in&#8221; 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&#8217;t usually come up in a sales conversation. <\/p>\n\n\n\n<p>Rather than asking about vendor lock-in, the better question is this: <strong>If you wanted to take your applications, your data, and your team and walk away, what specifically would break?<\/strong><\/p>\n\n\n\n<p>Of course, you can&#8217;t ask that question outright in a sales call. The vendor doesn&#8217;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. <\/p>\n\n\n\n<p>Run any platform on your shortlist through these questions, and the answers will tell you exactly what leaving would cost. <\/p>\n\n\n\n<p>The first one is the foundation. Everything else depends on the answer.<\/p>\n\n\n\n<!--more-->\n\n\n\n<h2 class=\"wp-block-heading\">Question 1: Where Does Your Data Physically Live?<\/h2>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/d4ey5ve3eb27c.cloudfront.net\/img\/blog\/where-is-your-data.png\" alt=\"\"\/><\/figure>\n\n\n\n<p>Where does the data your applications create and read actually sit? There are three possible answers:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the vendor&#8217;s cloud, in a database the vendor controls.<\/li>\n\n\n\n<li>In your cloud, but in a database schema and instance the vendor manages on your behalf.<\/li>\n\n\n\n<li>In your existing environment (either on-premise or in the cloud) and managed by you.<\/li>\n<\/ol>\n\n\n\n<p>Only the third option keeps the data layer in your hands. <\/p>\n\n\n\n<p>If the data lives in the vendor&#8217;s database, you do not own the schema. You do not own the indexes. You own the records, but you cannot run anything against them without the vendor&#8217;s runtime. Walking away means exporting flat files and rebuilding the rest from scratch. <\/p>\n\n\n\n<p>This is where many low-code platforms quietly lock you in. While the pitch might be &#8220;your data, your control,&#8221; the reality is &#8220;your data, in our database, accessible through our API, queryable through our query layer.&#8221; Many teams only realize it on the way out. <\/p>\n\n\n\n<p>Why does this matter: The moment your data lives in a database you do not control, you have outsourced your single most important IT asset. Everything else gets built on top of that decision.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Question 2: Whose Database Schema Runs Your Applications?<\/h2>\n\n\n\n<p>This one is closely related, but distinct. Even if the database itself sits inside your environment, who designed the schema your applications run against? <\/p>\n\n\n\n<p>If the answer is &#8220;the vendor&#8217;s schema that&#8217;s generated by their build tool and optimized for their runtime,&#8221; that schema is now a dependency. The applications you built are not really yours. They are yours-in-the-vendor&#8217;s-data-model. If you leave, the schema goes with them, and so do the years of business logic encoded in it. <\/p>\n\n\n\n<p>If the answer is &#8220;our existing schema, the one our database administrator already designed and that we already use for everything else,&#8221; your applications are layered on top of an asset you already owned. The vendor is producing applications that read and write the same database your team has been running for years. <\/p>\n\n\n\n<p>The difference shows up at year three. With a vendor-owned schema, your applications cannot be queried by other tools without going through the vendor. With your own schema, the reports, BI tools, integrations, and AI agents you build later can read the same data without paying the vendor to mediate the access. <\/p>\n\n\n\n<p>Ask the vendor directly: &#8220;Will my applications run against my existing tables, with my existing structure, or do you create a new database for your apps to live in?&#8221; The answer tells you whether you are extending your stack or moving into a new one. <\/p>\n\n\n\n<p>This is one reason on-premise low-code platforms that run directly over&nbsp;<a href=\"https:\/\/www.mrc-productivity.com\/solutions\/database-front-end.html\">existing databases<\/a>&nbsp;score so differently from cloud-native platforms on long-term flexibility.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Question 3: Can You Edit\/Export the Source Code You Built?<\/h2>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/d4ey5ve3eb27c.cloudfront.net\/img\/blog\/low-code-export.png\" alt=\"\"\/><\/figure>\n\n\n\n<p>A vendor might tell you their platform supports export. They might even point to a feature called &#8220;export.&#8221; <\/p>\n\n\n\n<p>But, what format? Can a developer outside the vendor&#8217;s ecosystem actually read and run the exported code? Does it use open languages, frameworks, or libraries? Or, is it a configuration file that only their runtime can interpret? <\/p>\n\n\n\n<p>Most low-code &#8220;exports&#8221; produce one of two things. Either a proprietary configuration file that re-imports cleanly only into the same platform, or a snapshot of metadata that describes the application but cannot run anywhere else. Neither is portable in any practical sense. <\/p>\n\n\n\n<p>A real export is source code. Compilable code, in a language with a public specification, that runs on infrastructure you can provision without the vendor. A language like Java, PHP, or .NET. Something your existing developers already work in. The kind of code you could maintain in-house if the vendor disappeared tomorrow. <\/p>\n\n\n\n<p>If the vendor&#8217;s only export is &#8220;you can keep using our platform under our license, but you can also generate a JSON file describing your app,&#8221; you are not exporting code. <\/p>\n\n\n\n<p>Why it matters: Source code portability is the single biggest practical determinant of switching cost. The team that can take a working application, run it on their own server, and maintain it with common programming language isn&#8217;t locked down.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Question 4: If You Stop Paying Tomorrow, Do Your Applications Keep Running?<\/h2>\n\n\n\n<p>This is the question that ends most discussions. <\/p>\n\n\n\n<p>For most low-code platforms, the honest answer is no. The applications you built only run while the vendor&#8217;s runtime is licensed and active. Stop paying, and your applications stop working. This is true even if the data is technically yours, the integrations are technically configurable, and the export is technically supported. The runtime is the dependency. No runtime, no app. <\/p>\n\n\n\n<p>What you are really licensing is the right to keep running the work you already paid to build. Each year you stay, the platform&#8217;s leverage compounds, because the cost of the runtime is a fraction of the cost of replacing what you have built. <\/p>\n\n\n\n<p>A platform where this is not true looks structurally different. The applications are&nbsp;<a href=\"https:\/\/www.mrc-productivity.com\/products\/build-process.html\">generated as standalone code<\/a>. They run on web servers you already control. The vendor&#8217;s tooling is required to build new applications and to update existing ones. The vendor&#8217;s tooling is not required to keep what you have already built running. <\/p>\n\n\n\n<p>If you stop paying, your team loses the ability to build new things. Your team does not lose the things they already built. <\/p>\n\n\n\n<p>Ask the vendor directly: &#8220;If our contract ends, will the applications we have built today continue to serve users tomorrow?&#8221; Listen to how they answer.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/d4ey5ve3eb27c.cloudfront.net\/img\/blog\/runtime-dependency.png\" alt=\"\"\/><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Question 5: Is the Price Predictable for the Next Five Years?<\/h2>\n\n\n\n<p>The last question is about money, but it is really about leverage. <\/p>\n\n\n\n<p>Most low-code platforms charge by some combination of users, applications, environments, transactions, or API calls. The exact meter varies. The pattern does not. As your business grows on the platform, your bill grows with it. The vendor learns how much you depend on them, and the renewal conversation reflects that learning. <\/p>\n\n\n\n<p>The pricing model is the lock-in mechanism most teams underestimate. You sign at year one when your usage is small. You discover the real cost at year three, when usage has grown five times over and switching means rebuilding everything from scratch. <\/p>\n\n\n\n<p>A platform with a predictable price has different economics. A&nbsp;one-time perpetual license, or at most a flat annual maintenance fee, does not increase the more you use it. The cost of running 50 applications is the same as the cost of running 5. The cost of supporting 500 users is the same as the cost of supporting 50.<\/p>\n\n\n\n<p>Run the math on the platform you are evaluating. Project usage at year three and year five based on what you already know about how your team uses tools. Calculate the total bill. That number is what you are signing up for, not the discounted year-one fee in the proposal.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What a Real &#8220;Open&#8221; Low-Code Platform Looks Like<\/h2>\n\n\n\n<p>Run any low-code platform through those five questions and the answer is almost always the same. A few yes answers, a few no answers, and a sense that &#8220;open&#8221; is a word doing a lot of work. <\/p>\n\n\n\n<p>A platform that passes all five tests won&#8217;t lock you down. The applications run on infrastructure you control, reading and writing to a database your team already owns. The code is exportable in a language your developers can maintain by hand. If you walk away, what you have already built keeps running. And the cost does not climb every time someone new logs in. <\/p>\n\n\n\n<p>We believe that low-code tools should be on-premise and perpetually licensed. As we explained in another article,&nbsp;<a href=\"https:\/\/www.mrc-productivity.com\/blog\/2026\/04\/what-software-should-not-be-saas\/\">low-code should not be SaaS<\/a>. Any business software that lets you build business applications with it should be owned by your organization, not rented from a vendor whose pricing, hosting, and uptime quietly become permanent dependencies the moment you put anything real on top of it. <\/p>\n\n\n\n<p>That belief is the reason m-Power works the way it does. The applications you build with&nbsp;<a href=\"https:\/\/www.mrc-productivity.com\/products\/index.html\">m-Power<\/a>&nbsp;run on-premise or in your own cloud, on web servers your team provisions. They read and write to your existing databases (IBM i, SQL Server, Oracle, DB2, MySQL, and others) using the schema your DBA already designed. The generated code is standard Java, PHP, or .NET, in a form your existing developers can read and maintain. If you stop paying maintenance, the applications you have already built keep running on your servers. The license is a one-time fee, and the price does not move when you add users, applications, or transactions. <\/p>\n\n\n\n<p>I am not telling you this because mrc is the only option that works this way. I am telling you because the five questions above describe what an honest answer to &#8220;do you lock me in&#8221; actually looks like, and we built mrc and m-Power to give that answer the same way for over 1,500 customers since 1981. <\/p>\n\n\n\n<p>Some of our customers have been running applications they built on m-Power for more than a decade. They are still using them. We did not have to be in the room for that to happen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Frequently Asked Questions<\/h2>\n\n\n\n<p><strong>What is low-code vendor lock-in?<\/strong>&nbsp;<\/p>\n\n\n\n<p>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.&nbsp;<\/p>\n\n\n\n<p><strong>How do I evaluate a low-code platform for lock-in risk?<\/strong>&nbsp;<\/p>\n\n\n\n<p>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.&nbsp;<\/p>\n\n\n\n<p><strong>Why does on-premise low-code reduce vendor lock-in?<\/strong>&nbsp;<\/p>\n\n\n\n<p>On-premise low-code platforms run the generated applications on servers the customer controls, against databases the customer owns. The vendor&#8217;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.&nbsp;<\/p>\n\n\n\n<p><strong>Is a perpetual license low-code platform better than SaaS low-code?<\/strong>&nbsp;<\/p>\n\n\n\n<p>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.&nbsp;<\/p>\n\n\n\n<p><strong>Does m-Power lock customers in?<\/strong>&nbsp;<\/p>\n\n\n\n<p>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&#8217;s continued operation. By the criteria above, m-Power is built specifically to avoid the lock-in patterns common in low-code SaaS.<\/p>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Definition Low-code vendor lock-in The practical inability to leave a platform after building applications on it. Caused by proprietary runtimes, vendor-owned database schemas, non-portable code exports, and usage-based pricing (not by contractual restrictions). One of the most common myths I&#8217;ve heard about low-code vendor lock-in is that it&#8217;s unavoidable. Pick any platform, the thinking goes, &hellip;<\/p>\n<p class=\"read-more\"> <a class=\"\" href=\"https:\/\/www.mrc-productivity.com\/blog\/2026\/05\/the-low-code-vendor-lock-in-test-five-questions-before-you-sign\/\"> <span class=\"screen-reader-text\">The Low-Code Vendor Lock-In Test: Five Questions Before You Sign<\/span> Read More &raquo;<\/a><\/p>\n","protected":false},"author":8,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"default","ast-global-header-display":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","slim_seo":{"title":"The Low-Code Vendor Lock-In Test: Five Questions Before You Sign - mrc&#039;s Cup of Joe Blog","description":"Definition Low-code vendor lock-in The practical inability to leave a platform after building applications on it. Caused by proprietary runtimes, vendor-owned d"},"footnotes":""},"categories":[8],"tags":[111],"class_list":["post-15546","post","type-post","status-publish","format-standard","hentry","category-education","tag-low-code"],"_links":{"self":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts\/15546","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/comments?post=15546"}],"version-history":[{"count":7,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts\/15546\/revisions"}],"predecessor-version":[{"id":15557,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts\/15546\/revisions\/15557"}],"wp:attachment":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/media?parent=15546"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/categories?post=15546"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/tags?post=15546"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}