No-Code App Builders: How Far Can They Take You?

A no-code app builder can ship a real, store-approved product in 2026 — the limit is rarely capability, it is ownership. FlutterFlow lets you download the Flutter source code; Bubble states plainly that your app cannot be exported as code. Decide on the exit cost, not the demo.

That distinction sounds like a technical footnote. It is actually the single factor that determines what your company owns three years from now. Below you will find six concrete limits — each checked against the platforms' own pricing pages and documentation — a three-year cost table, and the migration path you follow when a no-code app builder stops being enough.

Table of Contents

• What a No-Code App Builder Actually Does
• FlutterFlow, Bubble and Adalo: Three Different Products
• Subscription Math: Cheap Monthly, Expensive by Year Three
• Limit 1: Custom Integrations and Complex Logic
• Limit 2: Performance and Scaling
• Limit 3: App Store Policy
• Limit 4: Data Residency and Cross-Border Transfers
• Limit 5: Security and Governance
• Limit 6: Platform Risk
• The Exit Path: Moving to Custom Code
• No-Code or Custom Build: How to Decide
• Frequently Asked Questions

What a No-Code App Builder Actually Does

A no-code app builder replaces hand-written code with a visual canvas: you drag screens together, attach them to a database, and describe logic as "when the user taps this, do that." The platform turns those definitions into a running web or mobile application.

This is no longer a niche approach. Gartner's forecast put the low-code development technologies market at $44.5 billion in 2026, growing about 19% a year, with low-code tooling involved in roughly 75% of new application development — up from 40% in 2021 (Gartner data as reported by Le Monde Informatique).

So the useful question is not whether a no-code app builder works. It does. The question is whether it reaches as far as your product needs to go. For an internal reporting tool, a field data-collection app, a market test or an investor-facing MVP, these platforms are more than enough. For a product processing tens of thousands of transactions a day, with custom payment flows and regulated data, the answer changes.

One more distinction worth making: a no-code app builder is not the same thing as an AI tool that generates code from a written prompt. In the first, you design the logic visually; in the second, you inherit code a model wrote. We compared that second category against hiring a team in AI app builders vs a development agency. This article stays on the platforms.

FlutterFlow, Bubble and Adalo: Three Different Products

The three most popular options look similar in a demo and produce three technically different things.

FlutterFlow generates real Dart code for Google's Flutter framework. According to Flutter's own documentation, Dart code is ahead-of-time (AOT) compiled into native machine code on both iOS and Android, and the interface is drawn by Flutter's Impeller engine rather than a browser view (Flutter FAQ). FlutterFlow's ownership page is equally direct: "As you develop using FlutterFlow, you own the output of your work" (FlutterFlow docs).

Bubble started as a web app platform and now publishes iOS and Android apps from the same editor. Its documentation says native apps run on the device rather than through a wrapper — but also warns that inside the WebView element you use to reuse existing web pages, native capabilities such as location, camera and push notifications will not work. The decisive difference sits in Bubble's support article: "Bubble apps don't exist as code in the traditional sense, and can only run on the Bubble platform. There's currently no way of exporting your application as code" (Bubble support).

Adalo is the simplest of the three and the fastest start for a small team. Its pricing page shows zero publishable apps on the free tier — you need the Starter plan to reach the stores — and paid plans cap published apps at 1, 2 and 5 (Adalo pricing).

That third column summarises the whole article. Why code ownership belongs in the contract rather than the sales conversation is the subject of who owns your app's source code.

Subscription Math: Cheap Monthly, Expensive by Year Three

The strongest argument for any no-code app builder is the first invoice. But a subscription never ends, and the three-year total tells a different story. The figures below come from the platforms' own pricing pages and cover software only.

Store fees are fixed: the Apple Developer Program costs $99 per year (Apple) and a Google Play Console account carries a one-time $25 registration fee (Google). Bubble lists Starter at $59, Growth at $209 and Team at $549 per month on annual billing, with 50K monthly workload units on the free tier, 175K on Starter, 250K on Growth and 500K on Team (Bubble pricing). On FlutterFlow, code download and APK output unlock on the $39 Basic plan, GitHub integration on Growth (first seat $80), and one-click store deployment plus CLI access on Business (FlutterFlow pricing).

None of these totals include design, content, integration work, QA or maintenance. The platform subscription is the smallest line on a project budget; the largest is always human effort. To compare against a custom build on your own scope, run the numbers through our app cost calculator.

Limit 1: Custom Integrations and Complex Logic

Prebuilt connectors work beautifully for popular services. Trouble starts the moment you step off that list. When Bubble itself catalogues the drawbacks of no-code, the list includes "missing connectors" for niche tools and inadequate error handling in prebuilt integrations (Bubble blog).

Here is what that means in practice. Suppose your app needs split payouts through a payment provider's marketplace API, jurisdiction-aware sales tax, or a carrier's live rate endpoint. In a generic API connector you own four things yourself: the token call and its refresh when the token expires, a request body shaped to the service's schema, a retry-and-queue path for 5xx responses, and a reconciliation check confirming the record really exists on the other side. All four are buildable in a visual workflow — but your debugging surface gives you far less detail than a server log, and if you lean on a marketplace plugin, someone else decides how quickly it gets updated when the vendor changes a version.

The second bottleneck is business logic. Workflow editors are built for condition-and-action chains. Dynamic pricing, multi-step approval hierarchies, concurrency control on inventory reservations or a proprietary matching algorithm fit only by force. FlutterFlow lets you break through with custom actions and custom widgets written in Dart — and from that moment you pay for both the platform subscription and a developer. That is precisely where the economics of a no-code app builder crack.

Limit 2: Performance and Scaling

On Bubble, performance has a currency: the workload unit. The documentation defines it as "the server resources needed to host, run, and scale apps built on Bubble," consumed by page loads, workflows, searches and bulk operations. A badly built search raises your bill before your user count grows, and when traffic does grow, you meet the plan ceiling.

Three practical measures reduce consumption: paginate every list and stop fetching rows nobody sees; reach data through relational fields instead of repeated searches; and limit recurring background workflows to the ones that genuinely earn their keep. Those three changes move monthly consumption significantly — which also exposes the hidden cost of no-code. To run the platform cheaply, you have to learn the platform's internals.

Bubble names scaling and performance in its own drawbacks list: traffic spikes and "data and workflow volume" can degrade responsiveness under realistic load. The same post lists the cases where the platform is the wrong tool — ultra-low-latency or real-time processing at scale, products that need proprietary hardware or niche device APIs, and systems that must run on-premises.

FlutterFlow sits differently, because its output is compiled Flutter code. The scaling question simply moves to the back end: your data model, query patterns and security rules on Firebase or a similar service decide what happens at load. A no-code app builder starts fast; when it slows down, the layer you would profile and optimise often sits on the platform's side of the wall. We weighed those trade-offs in Firebase vs a custom backend.

Limit 3: App Store Policy

The wall no-code projects hit most often is editorial, not technical. Guideline 4.2 of Apple's App Store Review Guidelines requires features, content and UI "that elevate it beyond a repackaged website," and 4.2.2 rules out apps that are primarily marketing material, web clippings or a collection of links. The sharpest clause is 4.2.6: "Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content" (App Store Review Guidelines).

Read that carefully, because it does not ban no-code platforms. What it bans is a vendor cloning one template and submitting apps on behalf of clients. Publishing your own content from your own developer account keeps you outside 4.2.6 — provided the app is a genuine product rather than a shell.

Google writes the rule more concretely. Its functionality policy demands "a stable, responsive, and engaging user experience" and explicitly rejects static apps with no app-specific function, naming text-only or PDF apps and single-wallpaper apps as examples (Google Play policy).

The numbers show how real that threshold is. Apple's 2025 App Store Transparency Report records 9,100,620 submissions reviewed and 2,093,244 rejected, with 415,532 rejections in the Design category alone (Apple). Apple also reported turning away more than 371,000 submissions in 2025 for copying other apps, spam or misleading users. Work through our app launch checklist before you submit, and read the patterns behind refusals in app store rejection reasons.

Limit 4: Data Residency and Cross-Border Transfers

When you build on a no-code app builder, your users' data lives on the vendor's infrastructure, in the vendor's region. For a company handling EU or UK personal data, that is a transfer question, not a hosting preference.

Under Article 46 of the GDPR, a transfer without an adequacy decision requires appropriate safeguards — Commission-adopted standard contractual clauses, binding corporate rules, approved codes of conduct or certification mechanisms (GDPR Article 46). Transfers to US providers currently rest on the EU-US Data Privacy Framework, Commission Implementing Decision (EU) 2023/1795. That decision remains in force, but it is under live scrutiny: on 31 July 2026 the EDPB wrote to the European Commission asking it to "closely assess" whether the US Supreme Court's 29 June 2026 judgment in Trump v. Slaughter — which held that FTC commissioners are removable by the President — affects the functioning of that adequacy decision, since the decision itself relies on the FTC's independence (EDPB letter).

Practically, two consequences follow. First, your privacy notice, records of processing and vendor contracts must describe the transfer and its safeguard — that work is yours, not the platform's. Second, choosing where data sits is often not an option: Bubble's pricing page lists "choice of hosting location" only on the Enterprise tier, and Bubble's own drawbacks post names data residency and privacy-rule limits among the risks of no-code. If your sector adds HIPAA, PCI DSS or financial-services rules on top, confirm the platform's certifications before you design a single screen.

Limit 5: Security and Governance

A visual editor does not remove security decisions; it changes who makes them. OWASP renamed its project in this space to reflect how broad the problem became: the list now published as the OWASP Citizen Development Top 10 covers risks across no-code platforms, AI-assisted coding and AI agents (OWASP).

The first four entries match the mistakes we see most often in no-code app builder projects: CD-SEC-01 Blind Trust (accepting platform defaults without review), CD-SEC-02 Account Impersonation (flows that run under the creator's identity), CD-SEC-03 Authorization Misuse (access control left to the interface layer) and CD-SEC-04 Sensitive Data Leakage and Handling Failures. Entry nine, CD-SEC-09 Asset Management Failures, describes the enterprise version of the problem: live apps processing real data, owned by an account that belonged to someone who left the company.

Bubble's own list adds credential exposure, app proliferation, knowledge silos and pricing underestimated at scale. So before any no-code app builder goes live, put three things in writing: which roles may read which fields, who tested those rules at record level, and which corporate account owns the workspace and the billing. Role-level rules are the part teams most often assume the platform handles for them.

Limit 6: Platform Risk

The platform itself is a dependency. In 2026 the clearest example was Bildr, which closed with a note on its own homepage: "Bildr was built on a belief that creating software shouldn't require knowing how to write code. That world is arriving, and even though it won't be with Bildr…" (Bildr). Acquisitions produce the same outcome by a different route — Airtable announced that Dopt, which it had acquired, would "officially wind down on August 15, 2024" (Airtable).

None of this argues against using a platform. It argues against using one unprepared. Bubble tells departing customers it can supply a raw dump of application logic and visual design as a JSON file — a useful document, but not a running app. So plan three things from day one: a routine export of your data, a written copy of your business rules outside the platform, and a rough answer to "which architecture do we move to if this vendor disappears?"

Write that plan on a single page: which dataset is backed up where and how often, which corporate account owns the workspace, and which team moves what if the platform shuts down within a year. In organisations with a vendor-review process, that page turns the choice of a no-code app builder into a defensible decision instead of an unowned risk.

The Exit Path: Moving to Custom Code

Good news: starting on a no-code app builder and graduating to custom code is maturity, not failure. Bad news: teams who do it without a plan pay for the same product twice. A workable sequence:

1. Get the data out first. Bubble supports exporting user-created data as Excel-compatible CSV files and reading everything through a one-click REST API. Every migration begins with a dump of the data model.
2. Ask for the logic dump. Bubble's JSON export of app logic and design serves as a specification while you translate workflows into a new architecture.
3. Write the business rules in plain language. Which notification fires when, which field is mandatory, which role sees what. Without that document, a rebuild turns into guesswork.
4. On FlutterFlow, take the code. Paid plans let you download the Flutter project or push it to GitHub. Do not skip the documentation's warning: "FlutterFlow always pushes changes to a branch named flutterflow" and "Avoid making direct changes to this branch, as your changes will be overwritten by the next push from FlutterFlow" (FlutterFlow docs). The sync runs one way; hand-written code lives on a separate branch.
5. Audit the licences. FlutterFlow states that its generated helpers stick to permissive licences such as MIT or BSD-3-Clause, while warning that third-party Flutter packages may change licence terms.
6. Decouple the back end first. For most teams the lowest-risk order is to move the API and database to your own infrastructure, then hand over the interface.
7. Run both in parallel. Open the new build to a limited cohort while the old app stays live, sync data in both directions, then flip the switch.
8. Put repository ownership in the contract. If an agency takes over development, source-code delivery and repository transfer belong in the agreement from day one, not in a conversation at handover.

No-Code or Custom Build: How to Decide

The decision follows your product's next 24 months, not a feature checklist.

A no-code app builder makes sense when: you are testing whether demand exists; the app is an internal form, approval or reporting tool; one department's process is going digital; the product has a campaign-length lifespan; or the company has no technical team and needs a first step.

Custom development earns its cost when: your competitive advantage lives in an algorithm or an unusual workflow; mandatory integrations sit at the centre of the flow; regulation constrains where data may live; you use device hardware deeply; or the app is the company's main revenue channel. In Bubble's own words, millisecond-sensitive processing, proprietary hardware and on-premises deployment fall outside these platforms.

There is also a third road for teams in between: build the core in custom code and leave the supporting processes — internal tools, operations dashboards — on a no-code platform. We often recommend that hybrid in mobile app development projects, because you do not have to commit the entire budget to one architecture.

The cost side of a hybrid is clean, too: keep internal tools on an Adalo Professional or Bubble Starter tier and your yearly platform spend stays in four figures, while the custom-code budget goes only to the revenue-generating core. When growth arrives, the surface you have to migrate is smaller, because only operational flows live on the platform.

Frequently Asked Questions

Does a no-code app builder really require no code at all?

For simple apps, yes. Once you need a custom integration, unusual business logic or fine-tuned UI behaviour, platforms open a "custom code" door — and from there you need a developer. In practice most projects that start without code write some before launch.

Do I own the code of an app I build in FlutterFlow?

FlutterFlow's documentation says "you own the output of your work," and paid plans let you download the Flutter project. Code download starts on the $39 Basic plan and GitHub integration on Growth. So ownership is yours, while access depends on an active subscription.

Can I export a Bubble app as source code?

No. Bubble's support article states that its apps do not exist as code in the traditional sense and run only on the Bubble platform. You can export your data as CSV or through the API, and request a JSON dump of application logic when you leave.

Will Apple approve an app built with a no-code platform?

Yes, provided the app offers more than a repackaged website. Guideline 4.2.6 rejects apps created from a commercialized template or app generation service unless the content owner submits them directly, so publishing an original product from your own account keeps you clear of that clause.

How many users can a no-code platform handle?

There is no single user number. On Bubble the ceiling is workload-unit consumption: 50K units a month on the free tier, 175K on Starter and 250K on Growth. Heavy queries can exhaust the allowance before your user count grows, so workflow efficiency matters more than raw traffic.

How long does migrating from no-code to custom code take?

Complexity of the data model and integrations sets the timeline. The interface is usually rewritten from scratch; the real work is extracting every business rule and moving data without loss. Plan it as two versions running in parallel rather than a single cut-over weekend.

Is a no-code platform acceptable under the GDPR?

It can be, but compliance stays with you. Because the data is processed on the vendor's infrastructure, you need a valid transfer mechanism under Chapter V, an accurate privacy notice, a data processing agreement and records of processing. Check where the platform hosts data before you commit.

No-code app builders are the fastest way to get a product in front of users in 2026. FlutterFlow leaves the exit door open because it hands you source code; Bubble and Adalo trade that for speed and keep you on their infrastructure. This is not a good-platform-versus-bad-platform argument — it is a judgement about your product's lifespan, your data obligations and your growth plan.

Our advice is simple: ship the first version with whatever tool gets you there fastest, and from day one keep a data backup, a written copy of your business rules and an exit plan ready. If you want a second opinion on whether your current build should stay on a platform or move to custom code, get in touch — we will review the setup and map a path that scales with it.