Low-Code vs Custom Development: The Total Cost of Ownership Nobody Models
OutSystems and Mendix price per user, so the bill grows as adoption grows. A five-year TCO comparison against custom development, the specialist tax, and what leaving actually costs.
Low-code gets compared to custom development as if the two are the same purchase in different sizes. They are not, and that is why most of these cost comparisons are wrong before anybody opens a spreadsheet.
The comparison usually gets run once, in year one, on licence price against build price. Low-code wins that comparison almost every time. It is also the wrong comparison, because the two options have completely different cost curves and only one of them bends upward as you succeed.
Short answer
Low-code platforms like OutSystems, Mendix, and Power Apps charge per user per month, so the bill grows exactly as adoption grows. Custom development costs more in year one and less every year after. The crossover usually falls between year two and year three. The number almost nobody models is the exit cost, and on a low-code platform there often is no clean exit at any price.
Low-code and no-code are not the same purchase
These two terms get used interchangeably and they describe different products bought by different people for different reasons.
No-code means Bubble, Lovable, Webflow, Glide. The buyer is usually a founder or a small team. The price is $150 to $300 a month. The failure mode is hitting a ceiling on custom logic and having nothing portable to take with you. We covered that case in detail in no-code vs custom development in 2026, and if you are a founder building a first product, that is the post you want rather than this one.
Low-code means OutSystems, Mendix, Appian, Power Apps, Retool. The buyer is usually IT or operations inside an established company. The price is per user per month, negotiated annually, and at real headcount it reaches six figures. The failure mode is not a ceiling on capability, because these platforms are genuinely capable. It is that the cost scales with headcount forever and the asset you build is not transferable.
If you are evaluating OutSystems, the relevant comparison is not Bubble. It is a development team, and the honest way to compare those is over five years rather than one.
The pricing model punishes success
This is the structural thing to understand, and it has nothing to do with whether the technology is good.
Custom software costs what it costs to build, and then costs roughly the same to run whether ten people use it or ten thousand. Low-code costs per user, per month, forever. The better the tool works, the more people want access, and the more you pay for the same tool.
Run it at a plausible internal rate of $45 per user per month and watch what rollout does to the number:
| Users | Low-code, per year | Custom, per year after build |
|---|---|---|
| 25 (pilot) | $13,500 | Hosting and maintenance only |
| 100 (one department) | $54,000 | Unchanged |
| 400 (company wide) | $216,000 | Unchanged |
Nothing about the software changed between those rows. The only thing that changed is that it worked and people started using it. That is a strange thing to be billed for, and it is the single most common reason a low-code programme that looked cheap in the pilot becomes a budget problem in year three.
Talk to an engineer
Building something like this?
Skip the sales call. Tell a senior engineer what you want to build and get a straight answer on scope and cost.
The five-year total cost of ownership
Here is the comparison as it should be run, for a mid-sized internal application at around 100 users. Treat the numbers as a structure to fill in with your own quotes rather than as a prediction.
| Cost line | Low-code platform | Custom development |
|---|---|---|
| Initial build | Lower, and faster to a first demo | Higher in year one |
| Licensing, 5 years | $250,000 and up at 100 users | None |
| Specialist developers | Platform-certified, smaller hiring pool | Any competent engineer |
| Annual price rises | Set by the vendor at renewal | Hosting only |
| Cost of leaving | Full rebuild | Hand the repository to someone else |
| What you own at the end | A subscription | An asset |
The crossover point is usually somewhere in year two or year three. Before it, low-code is genuinely cheaper. After it, the gap widens every year and never closes again.
The specialist tax
A quiet assumption sits underneath most low-code business cases: that because the platform is easier, the people are cheaper.
In practice the opposite tends to happen. Once an application passes the simple stage, you need someone who knows that specific platform properly, and certified developers for the major low-code platforms are a much smaller pool than general software engineers. Smaller pool, comparable or higher day rates, and far less choice about who you work with.
It also does not transfer. A strong OutSystems developer is not interchangeable with a strong Mendix developer, and neither can be replaced by the general market. With a custom codebase in mainstream languages, any competent engineer can pick it up, which is a real form of insurance that never shows up as a line item.
The exit problem
Ask any low-code vendor what happens to your application if you stop paying. The answers are always polite and rarely reassuring.
These platforms compile to a proprietary runtime. Your application logic lives as platform metadata, not as code you could read, review, or hand to another team. Some vendors offer an export. It generally produces something technically valid and practically unmaintainable, which is not the same as portability.
So the honest way to describe leaving a low-code platform is not migration. It is rebuilding, at close to the original cost, under time pressure, while the existing system still has to run. That risk is real whether or not you ever exercise it, and it is worth pricing at the moment you sign rather than the moment you want to leave. It is the same question we work through in who owns your code, and the answer matters more on a five-year enterprise commitment than anywhere else.
When low-code is genuinely the right call
We build custom software, so treat this section with appropriate suspicion. It is still true, and we say it to prospective clients regularly.
Low-code is the better choice when the application has a known short life, such as supporting a two-year programme that ends. When it is standard workflow over data you already hold, with no meaningful competitive logic in it. When you already run the Microsoft estate and Power Apps is effectively bundled into licensing you pay for regardless. When you have no engineering capacity at all and the application is not central to how the business makes money. And when speed genuinely outranks everything, because a working process in three weeks can be worth more than a better one in three months.
The pattern across all of those: low-code wins when the application is a cost centre you want to stop thinking about. Custom wins when the application is part of how you actually compete, or when it is going to be in use for many years and many people.
How to run the comparison honestly
Four things turn this from a vendor pitch into a decision you can defend.
Model five years, not one. Use your projected headcount at year three, not your pilot headcount, because rollout is the entire point and the licence bill follows it. Get the vendor to put the renewal uplift in writing, since an unbounded annual increase on a platform you cannot leave is not a price, it is an option they hold over you. And ask both sides the same closing question: at the end of this, what do I own, and what happens if you and I stop working together?
Custom development answers that question with a repository, documentation, and the freedom to hire anyone. Low-code answers it with a renewal date. Neither answer is automatically wrong, but you should choose it deliberately rather than discover it in year four.
If the application in question is an internal system rather than a customer-facing product, the practical scoping questions are a bit different and we walked through them in custom internal tools and dashboards.
Frequently Asked Questions
What is the difference between low-code and custom development?
Low-code platforms like OutSystems, Mendix, and Power Apps let you assemble applications visually on a proprietary runtime, licensed per user per month. Custom development produces a codebase in mainstream languages that you own outright. The practical differences are who can maintain it, whether the cost grows with your headcount, and what you are left holding if the relationship ends.
Is low-code cheaper than custom development?
In year one, almost always yes. Over five years, usually not. Low-code charges per user per month, so the bill grows as adoption grows, while custom software costs roughly the same to run at ten users or ten thousand. The crossover typically lands in year two or three, and after that the gap widens every year.
How do you calculate total cost of ownership for a low-code platform versus custom development?
Model five years, not one, and include six lines: initial build, licensing at your projected year-three headcount rather than your pilot headcount, specialist developer rates, contracted annual renewal increases, ongoing maintenance, and the cost of leaving. That last line is the one most business cases omit, and on a low-code platform it is effectively a full rebuild.
What happens to my application if I leave a low-code platform?
Your application logic lives as platform metadata compiled to a proprietary runtime, so there is usually no export that produces a maintainable codebase. Leaving means rebuilding at close to the original cost, under time pressure, while the existing system still has to run. Price that risk when you sign rather than when you want to leave.
When should I choose low-code over custom code?
Choose low-code when the application has a known short life, when it is standard workflow with no competitive logic in it, when you already pay for the Microsoft estate and Power Apps comes with it, or when you have no engineering capacity and the application is not central to how the business earns. Choose custom when the software is part of how you compete or will be used by many people for many years.
Is low-code the same as no-code?
No. No-code tools like Bubble and Lovable are bought mostly by founders at $150 to $300 a month, and the usual failure is hitting a ceiling on custom logic. Low-code platforms like OutSystems and Mendix are bought by IT departments at enterprise pricing, and they are genuinely capable. The problem there is not capability, it is per-user cost that scales forever and an application you cannot take with you.
