Where low-code stops

How should you choose between app development platforms?

Decide the layer before you decide the vendor. App development platforms fall into three tiers that answer different questions: cross-platform frameworks for the product your customers touch, low-code platforms for the internal tools your staff touch, and no-code builders for workflows a business team can own outright. Most bad platform decisions come from applying one tier’s economics to another tier’s problem.

The framework argument gets the attention, but it is now the smaller decision. Flutter and React Native have converged far enough that either will ship a competent business application. The choice that compounds is where you draw the line between software you assemble and software you write, and what it costs to move that line two years later.

Three definitions worth fixing before any comparison. A cross-platform framework lets one codebase ship native-feeling apps on iOS and Android at once, trading some platform-specific control for development speed. A low-code platform supplies visual tooling and pre-built components so a team assembles most of an application and hand-writes only the edge cases through extension points. A no-code platform is the subset aimed at non-developers, built entirely through visual configuration with no code-writing option at all.

Flutter vs React Native: does the choice still matter?

Less than the search volume suggests. In the 2024 Stack Overflow Developer Survey, Flutter was used by 9.4% of all respondents and React Native by 8.4%¹, a gap too narrow for either to claim the default position. Sentiment tracks the same way: 60.60% of developers who had used Flutter said they admired it, against 56.50% for React Native¹.

The technical gap has closed as well. Flutter draws its own widgets through its rendering engine, which is why a Flutter screen looks the same on both platforms and why pixel consistency is cheaper to guarantee. React Native’s New Architecture, stabilised in 2024, removed most of the bridge overhead behind the old “Flutter is faster” argument. For the applications most companies actually build, list views, forms, authentication, payments and push, both are quick enough that users will not notice the engine underneath.

So choose on supply rather than on benchmarks. If your team already writes React on the web, React Native shares the mental model, the state libraries and frequently the same developers, which shortens onboarding for any web development team extending into mobile. If you are hiring fresh mobile capacity, the newer cohort leans the other way: among respondents learning to code, Flutter usage was 11.1% against React Native at 6.7%¹. That split is the closest thing available to a leading indicator on future hiring pools.

One reason the framework question stays live at all is store asymmetry. Android and iOS are not two equal halves of a market, and a single codebase is only a saving if it holds quality on the larger side.

Where do low-code platforms stop working?

At four predictable places, and none of them is “the app got popular”. Low-code platforms hit a hard ceiling on custom animation and bespoke interaction design, on offline-first synchronisation logic, on deep native API access such as Bluetooth peripherals, augmented reality and background processing, and on anything needing control of the render loop. Those are the concrete triggers for planning a custom rebuild. Popularity is not one of them, and neither is user count on its own.

The practical consequence is a sequencing rule. Read the next four quarters of roadmap before selecting a platform, not after. If a single item on it requires one of those four capabilities, the low-code route buys you a demo and then charges you a rewrite. If none of them appears, low-code will usually beat a custom build on time to first release by a wide margin, and the saved months are real.

Sprawl is the second failure mode, and it arrives quietly. Three-quarters of large enterprises already run at least four different low-code tools³, each with its own identity model, audit trail and export format. Nobody chose that portfolio. It accumulated one department at a time, which is why platform selection belongs to a standing governance decision rather than to whoever is closest to the budget.

Which layer of your stack should be low-code?

The internal one. The most durable pattern is a clean split: low-code for admin panels, back-office workflows, approval queues and internal dashboards, and fully written code for the customer-facing application. Internal tools have forgiving performance requirements, a captive user base and short shelf lives, which is exactly the profile low-code serves well. Customer-facing products have the opposite profile on all three counts.

The useful question is not whether to adopt low-code. It is which layer of your stack is allowed to be low-code, and who is permitted to move that boundary.

The direction of travel is not in doubt. Gartner’s trajectory has low-code moving from under 25% of new enterprise applications in 2020 to a forecast 75% by 2026, with an interim marker near 70% for 2025². That is a statement about volume, not about importance. The applications carrying a company’s differentiation are rarely the ones a visual builder can assemble, which is why the share can climb without the strategic picture changing much.

What does change is who is holding the tools. By 2026, developers outside formal IT are expected to make up at least 80% of the low-code user base, up from 60% in 2021³, and non-technical users alone were projected to reach 40% of all low-code platform users by 2025, up from 25% in 2023⁴. Governance has to move ahead of that curve. Decide now which data a citizen-built application may touch, where its output is allowed to be authoritative, and who reviews it before it becomes load-bearing.

What does Kotlin Multiplatform change for Android-first teams?

It removes the usual reason to compromise. Kotlin Multiplatform shares business logic, networking, persistence and validation across platforms while leaving the user interface fully native on each one. For an Android-first company expanding to iOS, that maps onto code the team already owns: the Kotlin domain layer travels, and the iOS engineers write SwiftUI against it rather than inheriting someone else’s widget system.

The trade is explicit. You maintain two interface layers instead of one, so headline development speed is lower than with a single-codebase framework. What you buy is the absence of the “this feels like a web page” complaint that dogs weaker cross-platform builds, plus native access to platform capabilities without a plugin sitting in the middle. For regulated products, and for anything where interaction quality is part of the value, that is usually the better trade. For a first market test on a fixed budget, it is not.

How do you price the exit before you commit?

Cost the migration at selection time, not two years in when the platform ceiling arrives. Vendor lock-in is the most consistently underestimated line item in low-code decisions, because the bill for it is deferred while the discount for it is immediate. Before signing, get a written answer to four questions: can we export the data model in a usable form, can we export the logic in any form, what happens to our integrations, and who owns the artefacts if we stop paying.

Then attach a number. Estimate the rebuild in engineer-months as though you had to do it next year, and carry that figure in the business case beside the licence fee. A platform that saves six months and would cost a hypothetical nine to leave is still often the right answer for an internal tool. It is rarely the right answer for the application your revenue depends on.

Scale is why the discipline pays. The enterprise mobile application development market was estimated at $168.45 billion in 2025 and is projected to reach $303.56 billion by 2030⁷, and the low-code platform market was estimated at $45.5 billion for 2025 on a 28.1% compound annual growth rate⁶. Treat all such figures carefully: research firms publish widely divergent numbers for the same year because their definitions of a low-code platform differ, so track one house consistently rather than averaging across them.

A decision matrix for app development platforms

Match the tier to the situation rather than shortlisting vendors first. The rows below describe company stage and binding constraint, which is what actually determines the answer.

Two habits keep the decision honest over time. Write down the assumption that justified the choice, then diarise a review for the quarter that assumption is due to expire. And keep platform selection inside normal delivery governance rather than beside it, since the same gates that run the software development life cycle should cover the platform choice, its security review and its exit test.

The pattern underneath all of it states in one line: assemble what is generic, write what is yours, and know the price of changing your mind. Teams that apply that consistently across mobile app development and the wider engineering portfolio spend far less time relitigating platform choices, because each choice was scoped to a layer instead of being sold as a strategy.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.