What No-Code App Builders Can and Cannot Do

Two decisions bring people to this question. Whether to build your product on a no-code tool or pay a team to write it properly. And whether the thing your staff use every day should stay on the platform somebody put together in an afternoon.

Both answers turn on a number that the platforms publish and almost nobody looks up first.

No-code means software you build by dragging pieces around a screen instead of typing code. Low-code is the same idea with an escape hatch, so you can drop into real code when the menus run out. We are COM8 STUDIO, a software company in Dubai, and we build custom software for a living. We still tell clients to start on a no-code tool more often than they expect.

The advice stops at a published number.

Why should you not trust the usual no-code statistics?

One number turns up within about thirty seconds of reading anything on this subject. It says that by 2025, 70 percent of new business software would be built with these tools rather than written as code. It is credited to Gartner, the research firm whose technology forecasts get quoted in sales decks.

We went looking for the original. We searched Gartner's own site twice, then the open web. The earliest version we could find is a software company's press release from September 2021, which quotes the number in a footnote and links to nothing. Several sites that repeat it have quietly changed the year to 2026 so it still sounds current.

That is a fair summary of how these tools get sold. Enormous confidence, very little checking.

So every price and limit below is quoted from the company that sells the tool, taken from its own help pages or price list, linked, and read in October 2026.

What does Gartner actually say about no-code?

Gartner treats low-code and no-code as one market. In its own words, a no-code platform is a low-code platform that "only requires text entry for formulae or simple expressions", which means the most typing you do is a sum, like in a spreadsheet cell.

Gartner adds a sentence the marketing leaves out. It says no code "is not a sufficient criterion" for letting non-technical staff build things, because "many complex tooling configuration tasks are no code but still require specialist skills."

That was published in February 2021, in the same release the 70 percent number is supposed to come from. The firm everyone quotes to sell no-code already said that removing the code does not remove the expertise.

What can you actually build without a developer?

Internal tools, forms and approvals, searchable directories, booking systems, and a first version of a product you want to test. Faster than a development team can do it.

• Internal tools. A page where your staff look up one customer's details, change a status, and move on. That one customer is one row in a table, and these tools call that row a record.
• Forms and approvals. A request arrives, somebody approves it, the next person is told.
• Directories and listings. A searchable list of properties, suppliers, courses or members.
• Bookings. A calendar, a slot, a confirmation email.
• A first version to test demand. Something real enough to put in front of customers before you commit a budget.

All five are mostly moving records around. Read a row, show it, change it, tell someone. No-code tools are built for that kind of work, and at it they are hard to beat on speed.

Two people read that list differently. If you run operations, you are looking at the job your team currently does in a spreadsheet with six tabs and one person who understands it. If you are building a product, you are looking at the cheapest way to find out whether anyone will pay. The list is the same. What it costs you to be wrong is not.

Where do no-code platforms stop working?

They stop at published numbers, and every platform prints them.

Bubble, a no-code tool for building web apps that run in a browser, publishes a page called hard limits. On it:

• 300 seconds for one automated job. Say "when a form arrives, check it, save it, email three people". Five minutes, then it stops.
• 50,000 rows from one sorted search. Ask it for a list ordered by date or price and that is the ceiling, not the first page of a longer list.
• 10,000 parts on one screen. Every button, box and rule you place there, counted together.
• 10,000 items in a list attached to one row, such as every order belonging to one customer.
• 1,000 kinds of thing per app. Customers, orders, invoices, one kind per table. Most businesses use a few dozen.

Bubble is candid about what happens past those points. If deleting one row means clearing more than 100,000 linked rows, it says the deletion "may be incomplete", so some old data quietly remains.

Airtable, a spreadsheet you can build small apps on top of, is blunter, because its limits are printed on the price list. One workspace, which Airtable calls a base, holds 1,000 rows on the free plan, 50,000 on Team and 125,000 on Business. When you reach the number, you cannot add more until you upgrade.

Fifty thousand sounds like plenty until you count rows rather than things. A property portal with 2,000 listings, twenty photos each and every viewing logged against them is already past it.

Airtable also limits how fast other systems can talk to it. When your website sends in orders automatically, Airtable accepts five of those messages a second per base and no more. Go over, and it refuses them and makes you wait thirty seconds.

Three things follow.

The limit belongs to the platform, not to your plan. Paying more raises some ceilings. It does not remove them. The 300 second cut-off is the same on every Bubble plan.

You find the wall by hitting it. Nobody reads a limits page while they are excited about an idea. They read it at 11pm when a report will not finish, or on the morning a launch works and the signup page starts timing out in front of the people who just arrived.

The wall arrives with your success. Each of these numbers depends on how much data you hold and how many people use your app. The better it goes, the sooner you meet them.

What do these platforms really cost once you grow?

A Zapier plan starts at $19.99 a month, and the same plan costs $2,199 a month once you are busy. The monthly price is not the problem. What the tool counts, and charges you for, is.

Most of these tools charge for something that grows when your business grows, such as one more staff login, one more row of data, or one more automatic job. So the headline price can stay the same while the bill underneath it keeps climbing.

Zapier, which connects separate tools so one can trigger the other, publishes every step of its price list. A task here means one step done automatically, like adding a row or sending an email. On the Pro plan, paid yearly:

Read your own row, not the bottom one. Most small teams sit between the first two. The plan and the product are identical in every row. Only the amount of work changed. Pay monthly instead of yearly and two million steps costs $5,099.

All prices below are the yearly-commitment rate, read on 12 October 2026.

• Bubble sells Workload Units, its own measure of computing work. Loading a page or saving a record spends a few. Plans are $59, $209 or $549 a month, each including a set number of units. Bubble emails you when you have used three quarters of them, and again when they are all gone, and after that you pay extra. The month your launch works is the month the bill moves, and you find out by email.
• Airtable charges per person. Team is $20 per user per month, Business is $45. Anyone who can edit the data is billed. A twelve person operations team on Business is $540 a month, and the next hire adds $45 before they have done any work.
• Glide, which turns a spreadsheet into a phone app, charges in credits that get spent as people use the app. Note the free plan: it allows zero published apps. You can build one, but nobody else can open it. Basic is $25, Plus is $50, Pro is $125 a month.
• Retool, used to build tools your own staff work in, bills twice. Ten dollars a month for each person who builds, and five dollars a month for each member of staff who opens what was built.
• Webflow, used to build websites visually, splits the bill in two. One charge keeps the site online, a second covers the people who edit it. You need both, so count both.

There is one more thing a price list cannot tell you. The way they count can change.

In 2023, Bubble replaced its pricing with Workload Units. The announcement thread on Bubble's own forum passed two thousand replies. Apps already running could stay on the old pricing for eighteen months, with a 10 percent increase. Bubble later said it could have communicated the change more effectively. An earlier attempt in 2022 was withdrawn after the community pushed back.

Nobody did anything wrong there. It is a normal commercial decision. But if your costs are set inside somebody else's pricing model, that model is theirs to redraw.

Can you take your app with you if you leave?

It depends entirely on the platform. Bubble says no, Webflow says partly, FlutterFlow says yes, and all three put it in writing.

Bubble: no. Bubble's own manual says there is "no way of exporting your application as code", and that Bubble apps "can only be run on the Bubble platform". The same page says that if you leave, you will have to rebuild the rules that make the app do anything, every if-this-then-that you set up. You own your data and your design. The part that makes it work does not come with you.

Webflow: partly, and the exclusion list is long. Webflow does let you take the code. Its help centre then lists what the export leaves out: the content system behind your blog and listings pages, user accounts, the online shop, pages in other languages, forms, site search and password protection. Protected pages, it notes, "will no longer be protected after code export." You get the shell of the site, not the site.

FlutterFlow: yes. It hands you the actual program code of your app, written in a language called Dart, which any mobile developer can pick up and continue. That starts on the $39 a month plan. From $80 a month it also pushes that code into GitHub, the standard place developers store and track code. Bubble's own comparison page calls this "FlutterFlow's clearest advantage over Bubble."

Getting your data out is a smaller question, and usually the answer is yes. Bubble gives you a spreadsheet file, or two formats a developer can load into another system. Data without the rules is just a filing cabinet.

How do you know you have outgrown a no-code platform?

Five questions. You can answer all five without knowing anything technical.

1. Is the bill rising for the wrong reason? If it grows because you added staff logins or rows of data, while the tool does exactly what it did last year, you are paying more for the same thing.
2. Are you working around the tool more than with it? One workaround is normal. A written list of workarounds that new staff have to be taught is a signal.
3. Has something stopped finishing? A report that gives up partway, a batch of data that stops loading, a page that takes too long to open. Those are the platform's limits, and you have reached them.
4. Do you know whether you could move it? If you have never checked what your platform lets you export, you have already made that decision by default.
5. What happens on the afternoon it stops? If it is an experiment, you lose an afternoon. If it is the product customers pay for, you lose the day's takings and some customers. If it is the tool your staff book jobs in, the work does not stop, it goes back to paper, and somebody re-keys two days of it on Monday.

One yes is fine. Three or more, and it is worth getting a price for building it properly instead.

What happens if the platform is switched off?

Your app stops working and your data goes with it, on a date the owner picks. It has happened twice, to platforms run by Google and Amazon.

Google App Maker, Google's own no-code tool for building staff apps inside a company's Google account, was announced for shutdown in January 2020. Existing apps stopped working on 19 January 2021, and data could be exported only until that date.

Amazon Honeycode, a no-code app builder from Amazon's cloud division, launched in June 2020 and ended on 29 February 2024. The notice is still printed at the top of Amazon's own launch announcement, and the wording is worth reading slowly: "After this date, you will no longer be able to use Honeycode or any of the apps you created in Honeycode."

Honeycode existed for three years and eight months, start to finish.

Google and Amazon owned both of these, and both companies are still in business. The platforms are gone, and so are the applications people built on them. Note what kind of applications those were. Both were internal staff tools, the safe-looking end of this decision.

It is a reason to decide, before you start, how much of your business can sit on a platform you cannot move it off.

What does moving off a no-code platform involve?

More than people expect, because most of these platforms will not give you the code your app is made of.

When you move ordinary software, the code comes with you. When the platform will not release it, there is nothing to carry. The rules are held inside a visual editor that only runs in one place. Somebody has to open every screen, read what it does, write it down, and build it again somewhere else.

A rebuild usually means:

• Writing down the rules, because they were never written down. They were clicked.
• Building that logic again from scratch in the new system.
• Moving the data, which is the easy part, and checking it, which is not.
• Reconnecting every other system it talks to, such as your accounting software, your email and your payment provider, because each connection was set up inside the old tool.
• Running both versions side by side until you trust the new one.

You will find articles claiming a rebuild costs a specific multiple of the original build. We looked for the source of those figures and could not find one. They appear with no method behind them, usually on the website of a company that sells migrations, so we are not going to repeat them.

We can say this much. The second build is rarely cheaper than the first, and it has to be done while the first one is still running the business. Our write-up on whether to build your own customer database or buy a ready-made one weighs up the same build-or-buy cost in a different setting.

Should you start with no-code or hire a developer?

Start with no-code when:

• You are testing whether anyone wants this at all.
• It is an internal tool for a known number of staff.
• The job is mostly forms, records and notifications.
• Being wrong costs you a few weeks, not the business.

Have it built as custom software when:

• The thing you are building is the business, not a tool that supports it.
• The limit the platform publishes, in rows or users, is below where you are heading.
• Your bill rises automatically every time you get busier.
• You hold data you may need to hand to an auditor, a regulator or another system.
• The answer to "can we leave" is no, and the thing matters too much for that to be acceptable.

One middle path people forget. You do not have to decide once, for everything. Plenty of companies keep the internal tools on no-code and have the customer-facing product built properly, and that split is often right.

Check three things before you assume the internal tool is the safe half. An internal tool on Airtable Business stops at 125,000 rows. An internal tool on Retool bills five dollars a month for everyone who opens it, so the same tool for 200 staff costs ten times what it costs for 20. And both platforms in the section above were internal tool platforms. The staff rota is not safer than the product. It is only cheaper to rebuild.

Our guide on how to choose a custom software development company lists the questions to ask a development partner. The same questions work for a no-code platform. Ask what it cannot do before you ask what it can.

The short version

No-code did not fail the people who used Google App Maker or Amazon Honeycode. It did exactly what it said it would, right up to the numbers it published. The mistake is not reading those numbers first.

If you are at that decision and want a second opinion, talk to COM8 STUDIO. We build custom software, and we will tell you to stay on the no-code tool if that is the right answer.