No-code tools that shut down, and what happened to the apps built on them

At least six well-known app-building platforms have been shut down or deprecated by their owners since 2020: Google App Maker (apps stopped working on 19 January 2021), Amazon Honeycode (29 February 2024), Airplane.dev (1 March 2024), Glide Classic Apps (30 June 2025), Google Tables (16 December 2025) and SAP Build Apps (deprecated 23 March 2026). In nearly every case users could take their data out as files or move it to a sibling product. The apps, meaning screens, logic and automations, mostly had to be rebuilt. The exceptions stayed inside the vendor: Glide offered a tool to convert Classic Apps into its newer format, and SAP later offered to turn web apps into code.

Which no-code tools have shut down?

What happened to the apps built on them?

• Google App Maker had the longest runway: almost a year from announcement to shutdown, citing low usage. Its data lived in Cloud SQL, in the customer's own Google Cloud account, so the data outlived the platform. Google had bought AppSheet two weeks before the announcement and pointed builders there.
• Amazon Honeycode launched in 2020 and was still in beta when AWS announced its end in August 2023. AWS stopped charging for it after 31 July 2023 and closed new sign-ups. Customers had about six months' notice to export their data as CSV (display values only: formulas, automations and app screens could not be exported); after 29 February 2024 neither Honeycode nor any app built in it could be used. If you are still running the workaround, see rebuilding Honeycode apps.
• Airplane.dev, an internal-tools platform that had raised $40.5 million, told customers on 3 January 2024 that Airtable had acquired the company and the product would close on 1 March. That left about eight weeks to replace tooling that many teams used for critical work. A former Airplane engineer wrote that the suggested alternatives, Windmill and Retool, were not drop-in replacements.
• Glide Classic Apps were Glide's original product. Glide renamed them Classic in March 2023, stopped anyone creating new ones in November 2023, and offered a tool that recreates a Classic App as a new Glide app on the same tables (some features, such as swipe screens and the shopping cart, could not be carried over). Glide's own pages disagree about apps nobody migrated: the March 2025 announcement said they would be migrated automatically, while the help page written after the deadline says they are permanently unavailable. More on where that left makers in the Glide alternatives page.
• Google Tables came out of Google's Area 120 incubator in 2020. Google's FAQ announced the end by May 2025: workspaces went read-only on 31 July 2025 and the product shut down on 16 December 2025. Users could export to Sheets, download CSV, or run a migration tool into AppSheet databases, which keeps relationships and column types but not uploaded files, bots or sharing settings.
• SAP Build Apps, which SAP bought as AppGyver in February 2021, was deprecated on 23 March 2026 and left SAP's eligible services list on 1 October 2026, with existing contracts honoured to their end. SAP's first guidance was that existing apps could not be migrated and had to be recreated with SAP Build Code or another tool. It later added an SAP-assisted, best-effort conversion of exported web apps into SAPUI5 or React code: a route from no-code into code, not into another builder. See replacing SAP Build Apps.

Why do no-code platforms get shut down?

Each closure was the owner's decision, usually driven by priorities elsewhere in the company. Four patterns cover almost all of them.

• Side projects at big companies. App Maker, Honeycode and Tables were each a small bet inside a company with bigger priorities. Honeycode never left beta. When the owner has a sibling product (AppSheet, twice for Google), users get pointed there.
• Acquisitions that close products. Airplane was an acquihire: Airtable wanted the team, not the product, and the product was gone within two months. Google's purchase of AppSheet came two weeks before App Maker's shutdown notice.
• Portfolio clean-ups. SAP bought AppGyver, rebranded it, then retired it five years later and pointed builders to its other SAP Build tools.
• Generation changes. Glide retired its own first product to focus on the second. A converter softens that, but the old product still ends on the vendor's schedule.

A fifth pattern is not a shutdown but hits budgets the same way: pricing restructures. In April 2023 Bubble replaced server capacity with a usage metric called workload, keeping legacy plans until 1 October 2024 with a price rise of about 10%. After Bending Spoons bought Evernote, free accounts were limited to fifty notes and one notebook from December 2023. The same owner now runs Airtable, which is why Airtable customers are asking what comes next.

What happens to my app if a no-code platform shuts down?

1. You get notice, sometimes not much. Across these six it ranged from about eight weeks (Airplane) to almost a year (App Maker). SAP is honouring existing contracts to their end.
2. Your data usually gets out. CSV downloads, an export to a spreadsheet, or a migration into the owner's other product. When the data already sat in your own database, as with App Maker on Cloud SQL, there was nothing to export.
3. Your app usually does not. Screens, logic, permissions and automations are stored in the vendor's own format, and no other builder reads it. SAP's first guidance said so outright; its later converter produces code, not an app another builder can open.
4. Published apps stop on the end date. The people using the app lose it that day, whether or not the replacement is ready.

How do I choose a no-code platform that will not strand me?

1. Where does the data physically live? Best is a database you own (your own Postgres) or a store you already rely on, with the platform as a layer on top. Next best is a built-in store with a tested export.
2. Can you export data and structure? Run a real export on day one, including files and attachments. Ask what format the app definition comes out in, and be realistic: no other builder will import it, so a written inventory of screens and automations is your real backup.
3. What happens to published apps if the vendor closes? Read the terms for a notice period, refunds of prepaid fees, and how long data stays downloadable after the end.
4. Who owns the company, and who might? A big company's side project, a venture-funded startup (acquihire risk) and a solo business (key-person risk) fail in different ways. Know which one you are buying from.
5. Is there a sibling product they would push you to? If the owner sells another builder, ask why this one exists.
6. How stable is the pricing meter? One unit you can count before you build (users, seats) is easier to plan for than a usage meter you discover in production.

How does Emberblocks answer that checklist?

Emberblocks should be held to the same list, and one answer is uncomfortable. It is built and run by one person, Apostolos Papadopoulos, in Thessaloniki, as a sole-trader business with no venture funding (see about). There are no investors pushing for an acquihire or a quick exit, and there is key-person risk instead: if the founder stops, the service stops.

The honest mitigation for the owner risk is where you put the data, not a promise. Build on your own Postgres, or keep Airtable as the source, and the app layer becomes the replaceable part: if Emberblocks disappeared, the rows would still be in your database or your base. The data sources guide covers how each source works.

Where Emberblocks is the wrong pick: if your procurement needs a vendor with a sales team, a support tier and compliance certifications, it has none of those. If you need native store apps, it builds web apps that install to a phone's home screen instead.