That matters because the license fee is the number that gets approved. It is on the quote, it goes into the business case, and it is what the CFO remembers. The other costs appear later as operating expenses, spread across different budgets and different teams, so nobody adds them back together.

Seven costs are worth including, and they behave differently across a three-year term. The figures used here are examples rather than benchmarks, because no two portfolios are alike. What transfers is the structure, filled in with your own numbers.

Vendor lock-in is usually treated as a technical objection, something architects raise and finance ignores. It is more useful to treat it as money. Lock-in has a price: it is the amount you overpay at renewal because leaving would cost more. Once you calculate that figure, the argument stops being about principle and becomes a line in a spreadsheet.

Why the license price tells you so little

Enterprise low-code platforms use several different pricing structures, and the structure matters more than the headline number.

Take one worked illustration. OutSystems Developer Cloud publishes a starting subscription of roughly $36,300 per year covering 100 internal users, while independent transaction data puts its average annual contract value at about $220,000, within a range running from roughly $18,000 to $340,000. Both figures are accurate. They describe different customers.

That gap is not unusual, and it is not specific to one vendor. It is what happens when published pricing describes an entry point and enterprise pricing is negotiated. Most enterprise platforms direct serious buyers to a personalized quote rather than a rate card, which is why any third-party figure you find, including the ones in this article, is an estimate to validate against a quote of your own.

The structures themselves also differ in ways that resist comparison. Some platforms meter by application object, counting screens, entities, and API methods. Some charge per user, with volume tiers. Some exclude compute from the license entirely and bill infrastructure separately. Run the same portfolio through two of those models and you get two completely different cost curves, with a crossover point that depends on your specific mix of applications and users.

So the number you are quoted is a negotiated position within a wide range, and it covers only one of several costs you will carry.

This is also why year one rarely reveals the problem. Low-code platforms genuinely are cheaper and faster to start with, which is most of why organizations buy them. The difficulty appears in years two and three, when consumption has grown, the specialist team has been hired, and the administration workload has become somebody's full-time job. By then the platform is embedded and the comparison you should have run at signing is much harder to act on.

The seven costs worth modeling

Seven categories capture the material cost of an enterprise low-code platform. The first three are usually modeled. The next three are usually absorbed. The seventh is almost never priced at all.

Populate each one for years one, two, and three separately. Costs that look flat in year one rarely stay flat.

Base license

The contracted subscription for your current portfolio and user count. This is the only figure most business cases contain.

Model the contract term honestly. A three-year committed deal with a fixed escalator is a different financial instrument from an annual renewal, and the difference in flexibility has a value you should note even if you cannot yet quantify it.

License growth as the portfolio grows

The line that turns a good business case into a bad one.

Where licensing is metered by application objects, screens, entities, API methods, or capacity units, cost rises as applications succeed. This is arithmetic rather than a forecast. Add a screen, add a cost. Add an integration, add a cost. Your bill can rise substantially at renewal without the vendor increasing a single price, because the growth came from your own success in using the platform.

Model this at your actual historical growth rate, not at zero and not at the vendor's assumption. If you have two renewals of history, you already have the number.

Recommendation: run this at three growth rates, low, expected, and high. The spread between them is the volatility you are underwriting.

How a platform prices matters more than what it charges. Where license cost is separated from application growth, which is how Betty Blocks prices, this cost stays flat and your renewal depends on the contract rather than on how much you built. Where cost is metered by object, entity, or capacity unit, it does not stay flat.

Specialist talent

Complex work on enterprise low-code platforms requires platform-specific skills, and those skills carry a market price.

Salary data for developers certified on one major enterprise platform puts the US average at approximately $110,700, with the middle of the range between $84,000 and $134,500. Fully loaded, including employer taxes, benefits, and overhead, add roughly 25 to 35% to that figure.

An important caveat, because getting this wrong overstates the case. You would employ developers regardless of platform. The cost attributable to the platform is the premium over a general-purpose developer in your market, plus the cost of scarcity: longer time to hire, higher contractor rates, and the delivery capacity you lose while a role sits open.

Recommendation: model total specialist cost, then model the platform-attributable share separately. Present both. A business case that claims the entire salary bill as a platform cost will be dismissed by anyone who has hired a developer.

The question underneath this cost is who is allowed to build. If every meaningful change needs a certified specialist, the cost is set by how many of those specialists exist, and more budget will not produce them faster. If AI-driven generation and a business-accessible interface let more people contribute, hiring becomes a choice rather than a bottleneck.

Governance and administration overhead

Platform administration, environment management, access reviews, upgrade testing, and center-of-excellence activity. Typically a fraction of an FTE at small scale and one to three FTEs at portfolio scale.

The size of this depends heavily on whether governance is inherited automatically by every application or configured per application. That architectural difference has a direct headcount consequence, which is why it belongs in a cost model rather than a technical evaluation.

Some platforms apply DTAP separation, role-based access control, audit logging, and CI/CD integration automatically to every application they generate. Others leave each of those to be configured per app. The difference that matters here is simple: either governance is ongoing work someone has to do, or it is built into how the platform operates. Only the second one scales without adding headcount.

Recommendation: ask each vendor what a business user must do to bring an application into a governed state, then convert the answer into FTEs at your target portfolio size.

Infrastructure, integration, and add-ons

Everything priced outside the base rate card.

Some vendors state plainly that compute is not included in license pricing and is budgeted separately. Others cap database storage or custom code execution time and require separately priced add-ons when those caps are exceeded. Premium connectors, additional environments, higher support tiers, and non-production runtimes commonly sit outside the headline figure.

Recommendation: ask the vendor for a written list of everything that can generate a charge outside the base subscription. Not what will, what can. The gap between those two answers is informative.

The question this category really settles is how many separate charges a platform can generate. A single predictable spend line is far easier to forecast and defend than a base subscription with a variable tail attached, and the difference is testable: compare the written charge list from each vendor on your shortlist

Exit cost

What it would cost to leave, if you decided to.

There is no reliable public benchmark for this figure, which is part of the problem. Vendors have no reason to publish it and buyers rarely calculate it until they need it, by which point the number is no longer negotiable.

Build your own from components you can price: re-implementation effort per application, data migration, retraining, integration rework, and the period during which you would pay for both platforms at once. A rough figure calculated this year is worth more than a precise one calculated during a renewal.

This is a contingent liability rather than a cash cost, and it should be presented as one. But contingent does not mean zero. Your organization prices other contingent liabilities. This one deserves the same treatment.

The optionality premium

The value of the choice you no longer have.

When leaving is expensive, your negotiating position at renewal weakens in direct proportion. The mechanism is straightforward. By year two, a successful deployment has applications integrated across the surrounding stack, and the cost of unwinding exceeds the cost of accepting an above-market increase. So the increase gets accepted, and the same logic applies again at the renewal after that.

That is lock-in expressed as money rather than as a principle. It is the amount above market you pay because leaving would cost more, and it grows at every renewal.

Quantifying it precisely is difficult. Quantifying it roughly is not: take the difference between your renewal increase and the increase you would have accepted with a credible alternative in hand.

Two platform properties reduce this cost rather than the license cost. Code you can genuinely own and continue developing preserves a credible alternative. So does deployment control, meaning the ability to run on-premises, in EU cloud, or hybrid, because a platform that cannot meet a new compliance obligation removes your choice regardless of what the contract says. Both belong in the cost model rather than in a features comparison.

A worked example

The figures below are illustrative. They are not a customer case study and not a benchmark. They exist to show the shape of the model. Substitute your own numbers.

Scenario: a mid-size enterprise portfolio. 25 applications, 400 users, three-year horizon. Year one contracted license of $180,000. Consumption growth modeled at 20% annually, an assumption you should replace with your own historical rate. Four platform-certified developers at $110,000 base, loaded at 30%. Half an FTE of platform administration at $150,000 loaded. Infrastructure, connectors, and add-ons at $40,000 per year.

Licensing comes to $655,200 across three years. Against a visible total of $2,716,200, that is roughly 24% of what the platform costs.

Three things worth noticing in that table.

The talent line dominates, at 63% of visible cost. Only the platform-attributable premium within it belongs to the vendor, but the scarcity of that talent is a platform characteristic, not an accident.

Consumption growth adds $115,200 over three years compared with a flat $180,000 per year, and the annual bill rises 44% between year one and year three. No price increase was issued. It arrived as consumption.

The exit cost is not in the visible total, and that is the point. It is the number that determines your renewal negotiation, and it appears nowhere in the business case that approved the platform.

Three scenarios, compared

At renewal, most organizations are choosing between three futures. Modeling all three, rather than defaulting to the first, is the entire value of doing this exercise.

The third column deserves attention because it is the one people forget to compare. If your vendor requires you to rebuild applications to move onto its current architecture, you are already funding a rebuild. The switching cost you were worried about is sunk. At that point the honest comparison is not migrate versus stay, it is rebuild here versus rebuild somewhere with better three-year economics.

What "no lock-in" claims actually mean

Every low-code vendor now has a position on lock-in, and the positions are more similar than the marketing suggests.

The standard claim is that the platform compiles or exports to standard code that can run without the vendor's runtime, and several offer an explicit detach or export process producing conventional .NET or JavaScript output. That claim is usually technically accurate, and it deserves to be represented fairly rather than dismissed.

The practical question is different from the technical one. Exported code is a snapshot: the generated output frozen at the moment of export, not a continuation of the development workflow. From that point on, a low-code workflow becomes a hand-maintained codebase, written for a compiler, inherited by developers who did not design it.

Vendors dispute that characterization, and buyers should treat it as a live disagreement rather than a settled fact. What is not in dispute is the test.

Ask to see an actual export from a live environment during evaluation. Then ask whether a developer unfamiliar with the platform could pick it up and extend it. Code you can run is portability. Code you can develop is ownership. Most "no lock-in" claims describe the first and are read by buyers as the second.

Ask three more things in writing: whether export is available during the contract or only at termination, whether it carries an additional fee, and whether the right survives termination for cause.

This is also where platform architecture starts to affect the cost model directly. Platforms built so that exportable, standard code is the normal deliverable rather than an exit mechanism, which is how Betty Blocks approaches it with React and WebAssembly output, changing the exit cost and the optionality premium rather than the license figure. Whether that difference is worth anything to you depends entirely on your own growth trajectory and how much value you place on keeping the next decision open. Run the model and see.

When a higher-cost platform is still the right decision

Cost modeling is a tool for making a decision, not an argument for the cheapest option. Three situations justify paying more.

Genuine enterprise-scale complexity. Some platforms handle transaction volumes, integration density, and regulatory workloads that others do not. If your requirements sit at that end of the spectrum, the premium buys something real.

A mature, productive existing investment. An organization three years into a well-governed deployment with trained teams and a working delivery cadence has accumulated capability that does not transfer. Switching costs are real in both directions.

A stable portfolio. If your application count and user base are genuinely flat, consumption-based growth never triggers, and the compounding problem this article describes does not apply to you.

The test is whether you can name which of these applies to you. If the only answer is that you are already on the platform, that is not a reason to stay. That is the switching cost being used as an argument.

What to do with this

Cost these seven categories for your own portfolio this quarter, before your next renewal cycle rather than during it. The exercise takes a few days and it changes the conversation permanently, because you arrive with a model instead of a reaction.

Two habits are worth adopting alongside it. Recalculate license growth every year against actual consumption, so growth surprises become forecasts. And keep the exit cost current, because an exit cost you have quantified is an exit cost you can negotiate against, whether or not you ever intend to use it.

If you do only one thing, work out what it would cost your organization to leave its current platform in year three. If nobody can answer that today, you have learned something worth knowing before a renewal rather than during one.

Lock-in is not a reason to rule out a platform. It is a cost like any other, and it can be priced. The organizations that get caught out are not the ones that accept lock-in. They are the ones that never worked out what it was worth.