Low-code vs custom development: how to choose, and what each really costs

Pick a low-code platform for an internal application of low to moderate complexity, with a predictable number of users, when your organisation already owns the platform or the skills to run it. Pick custom development when the application is core to your business, will be sold to or used by customers, will grow in users, or when you refuse to depend on one vendor to evolve it. Decide on three-to-five-year cost and on what you own at the end, not on how fast the first screen appears.

Search for this topic and most of what you find is written by low-code platform vendors, who all have an interest in the same answer. This guide takes the other side of the table: where low-code genuinely wins, where custom code catches up, and what each path costs, using published prices.

Low-code, no-code, pro-code: three different things

• No-code (Airtable, Bubble, Glide and the like) is for business users who assemble an app without code. Fast, accessible, quickly limited. We cover it in agency vs freelancer vs no-code and in Airtable's limits.
• Low-code (Mendix, OutSystems, Microsoft Power Apps, Retool and others) is for developers and technical staff: screens, data and workflows are modelled visually, and code fills the gaps. Enterprise platforms come with their own certifications and specialist developers.
• Custom development, sometimes called pro-code or high-code, is written in standard languages (TypeScript, Python, PHP, Java…) on open-source frameworks and hosted wherever you choose. The code is an asset any competent team can take over.

This article is about the contest between the last two. If you are weighing one specific tool, see our dedicated comparisons for Power Apps and n8n.

Side by side

Neither column is "better". They solve different problems.

Published prices, checked on 7 November 2026

Low-code vendors rarely publish complete pricing. Here is what was publicly listed on that date (pages viewed from Europe, prices in euros):

• Mendix: the pricing page shows a free tier, then a Standard plan starting at €918 a month for one app and starting at €2,295 a month for unlimited apps. Premium is quote-only. The page says pricing depends on the number of apps and users, and that cloud resources are not included in the paid licences.
• OutSystems: the editions page publishes no price for its enterprise platform, which is quote-based. A free Personal Edition exists for learning. Pricing depends on "Application Objects" (screens, tables, API methods) and on internal and external user counts.
• Retool: the public pricing lists its Business plan, billed annually, at €46 per builder per month and €14 per internal user per month.
• Power Apps: licences are broken down in our Power Apps vs custom app guide.

Run the numbers over three years. One Mendix Standard app at the listed entry price is €918 × 36 months, or €33,048 in licences, before cloud hosting and before any developer time. The licence does not replace the developer. It comes on top.

What custom development costs over the same period

Custom software is paid for differently: an upfront design and build cost, then modest hosting and maintenance. The first item depends on scope, not on user count, which is why custom code becomes competitive as an application opens up to more people. Our breakdown of custom business application cost lists what moves a quote.

One point this debate usually misses: custom development does not have to be paid upfront. At LPR Studio it can be funded either as a fixed-price project or as a monthly subscription that spares you the development cost, like a licence, but for software built around your needs. The two models are compared in subscription vs upfront build.

When low-code is the right call

• An internal application: requests, approvals, activity tracking, field data capture, for a stable number of users.
• You already own the platform: licences in place, a trained team, IT governance rules defined.
• A time-boxed need: a tool for one project, a reorganisation, a transition period.
• An internal prototype to validate a process before deciding what comes next.
• Standard logic: forms, lists, tables, conventional approval flows.

When custom development pays off

• The application is your product, or a service you deliver to customers: SaaS, client portal, marketplace. Per-user licences eat the margin, and the interface has to be flawless.
• User numbers will grow, or include partners and external customers, whom low-code price lists often charge separately.
• Your business logic is your edge: pricing engines, scheduling rules, regulatory checks. If everything that matters ends up as custom code inside the platform, you are paying the platform for nothing.
• You want control of hosting and data location (hosting a business application in Europe).
• You refuse dependence: prices set by the vendor, roadmap at its pace, developers scarce on its technology.
• The application must last ten years: standard, documented code can be picked up by any competent team.

Vendor lock-in is the real issue

The main risk of low-code is commercial rather than technical. Once the application is built, the vendor sets the renewal price, and leaving means rebuilding. Before signing, ask four questions in writing:

1. What do we get back if we leave? Data in which format? Logic in a form that runs elsewhere, or only documentation?
2. How does pricing scale? Per user, per app, per capacity? What happens if users double?
3. What is included? Hosting, test environments, support, backups.
4. Where is the data hosted, and under which jurisdiction?

The same questions apply to a custom development partner. There, code, data and documentation are covered by rights defined case by case in the contract. Our vendor lock-in exit plan explains what to secure before you commit.

The IT department's view: governance and shadow IT

Low-code has a side effect vendors rarely highlight. When every department can build apps, the estate multiplies without an inventory, without controlled backups and without a named owner. A critical application can end up depending on one person who then leaves. If you adopt a platform, adopt its rules too: an app inventory, separate environments, a review before production, and a named owner for each app.

Where AI fits in

AI coding assistants and app builders have narrowed the speed gap on simple screens: a well-equipped developer now ships a standard interface almost as fast as a visual platform. What has not changed: someone still has to design, review, secure, test and operate the result. We go into this in AI app builders vs a software studio.

Common mistakes

• Comparing a low-code first screen with a full custom quote. Compare two finished applications, in production, over the same period.
• Leaving external users out of the licence calculation.
• Building a commercial product on an internal platform, then finding the pricing model breaks at a hundred customers.
• Adding code everywhere to work around platform limits: you end up with the drawbacks of both approaches.
• Choosing without seeing. A vendor demo shows the platform, not your application.

The hybrid route

The two approaches coexist well. Low-code can carry the small internal tools, while the core application, the one that sets you apart or faces customers, is built in custom code and exposes an API the platform consumes. Each does what it does best.

A decision grid

Where to start

1. Describe the application on one page: who uses it, how many people in three years, which rules, which integrations.
2. Get a complete low-code price: licences for every user, hosting, environments, developers.
3. Get a custom price for the same scope, both fixed-price and subscription.
4. Compare over three and five years, and look at what you own at the end.

For the custom side, you do not have to buy from a plan. We build a free prototype, presented on a video call within 5 working days, that you can put next to the vendor's demo. The idea is explained in see your software before you pay.