Bubble web apps and FlutterFlow mobile apps, built to last past version one

Which tool fits which product

If you need both a web and a mobile product, share one backend rather than copying data between two tools. A common shape is a web admin and a mobile app that read the same API.

Neither tool is right for everything. Heavy real-time features, complex offline-first behaviour, deep device integration and very large scale usually point to custom code. Our article on native or cross-platform covers the mobile side, and Flutter development is the next step if a FlutterFlow app outgrows the builder.

How we model the data first

Before we open either tool, we write the data model on paper: the things your product tracks (users, organisations, orders, bookings), their fields, how they relate, and who may see and change each one. This is the part that is most expensive to fix later, and it is what a minimum viable product most often gets wrong.

• One source of truth for each fact. Do not copy values between records unless you must.
• Use relationships and references instead of typing names as text.
• Give every record an owner and a status field, so rules and reports stay simple.
• Name fields plainly and document them, because the exit plan depends on it.
• Keep anything you search or filter as its own data type, not as a huge text field.

In Bubble these become data types and fields. In FlutterFlow they become collections or tables in your backend. Either way, the model should make sense to someone reading it without the tool open.

Integrations: Airtable, Zapier and APIs

Most no-code products connect to something else. The question is who maintains each connection when it breaks.

Airtable

Airtable suits operational data that staff edit by hand, such as a catalogue, a content calendar or a pipeline. It is a weak home for private per-user data at application scale, and its API has request limits. Scope each access token to the bases it needs and no more.

Zapier

Zapier connects apps through triggers and actions without code. Each step runs with the permissions of the account that connected it, so use a shared service account rather than one person's login. Add alerts for failed runs, because a broken automation fails quietly, and keep a list of every automation with an owner.

APIs and webhooks

When a tool offers an API, prefer it over a chain of automations for anything central to the product. Call it from the server side of the platform, keep secrets in private fields, and verify incoming webhooks with a shared secret or signature so that a stranger cannot post fake events.

The security pitfalls of no-code

Visual builders make it easy to ship, and just as easy to ship something open. These are the failures we look for first. Broken access control is the first item in the 2021 edition of the OWASP Top 10, and no-code apps meet it often.

Open data by default

In Bubble, check the privacy rules on every data type. A page that hides a button is not access control: if a data type can be read by any logged-in user, anyone who knows how to ask can read it. Test by signing in as a second user and trying to reach the first user's records, and by calling the data API without credentials. In FlutterFlow the phone talks to the backend directly, so the rules live in the backend: Firebase security rules, or row-level security in Postgres.

Exposed API keys

Anything that runs in the browser or in a mobile app can be inspected. Keys for payments, email, billed maps and AI services belong in server-side workflows or a small backend, not in client-side fields or app settings. Use restricted keys where the provider offers them, and rotate any key that has leaked.

Weak role rules

Roles must be enforced where data is read and written, not only in the interface. Do not store a role in a field the user can edit, do not rely on hidden admin pages, and test each role with a real account. Run workflows with the lowest rights that work and validate every input they receive.

Plugins and uploads

A plugin can read your data, so look at who maintains it and what it asks for, and keep the list short. Check whether uploaded files can be reached by anyone who has the link.

We start with a threat review and finish with a security review and a prioritised fix list, on a no-code build as on a coded one. See threat modelling for how that works.

Vendor lock-in and a written exit plan

Lock-in is the price of speed, and it is acceptable when you see it clearly. With Bubble, the app's source code is not yours to run elsewhere, so a move means rebuilding from the data and the written logic. FlutterFlow can export Flutter code, but treat export as a one-way door: once developers edit the exported project by hand, you generally cannot send it back into the visual builder.

So we write the exit plan on day one and update it as the product changes. It covers six things.

1. Data. How to export every data type or collection, how often, and where the copy is stored. Test a restore, not only an export.
2. Logic. Every workflow described in plain language: trigger, conditions, effects.
3. Design. The interface kept in Figma, so it can be rebuilt on any stack. See UI/UX design.
4. Accounts and keys. Who owns each login, key, webhook and domain.
5. Triggers. The signals that start a move, such as cost, speed or a feature the tool cannot build.
6. Target. The likely replacement, for example a Next.js app with PostgreSQL or a Flutter codebase, and the order to move things in.

Performance limits to plan for

Bubble pages do real work in the browser, so pages that search and filter big lists on the client, nest lookups inside lookups or load a whole list to show ten rows get slow. Constrain searches in the database, paginate, and keep pages light. FlutterFlow apps are Flutter apps, which keeps the interface responsive, but heavy queries, large images and many live listeners still hurt. Test on mid-range Android phones and slow connections.

Platform plans also cap capacity and usage in ways that show up under load. Test with realistic volumes before launch, not with ten sample records, and check what a busy month would do to your plan.

When to graduate to custom code

Graduate when the tool is the bottleneck, not when it feels unfashionable. Typical signals:

• A feature you need cannot be built, or only through a growing pile of workarounds.
• Performance problems remain after the data and pages are tidied.
• Compliance or customer security reviews ask for controls the platform cannot show.
• The platform bill grows faster than your revenue.
• The team spends more time working around the tool than building.

You do not have to rebuild everything at once. Move the heaviest or most sensitive part first, keep the rest running, and reuse the data model. Our guide to choosing how to build your product and the article on build versus buy help with the decision, and web and mobile development are where the work goes.