AI app builder platform deprecations (September 2026): what happens to your app when the vendor moves on

Quick answer, September 2026. Every comparison of AI app builders asks what happens when you want to leave. Almost none asks what happens when the vendor moves on without you. Those are different risks, and the second one arrives on a date you did not choose. Across the eight builders here, a platform change lands on a shipped app in one of three ways: the capability is disabled on a fixed date, the app is frozen so it keeps running but can no longer be edited, or you are grandfathered onto an old branch that works indefinitely while the product moves on without you. The received ranking says that owning your code protects you. On this axis it does not remove the problem. It changes who is on the hook, and it changes who is allowed to say no.

The three things a deprecation can do to a running app

Most people picture deprecation as breakage. In the documentation of these eight vendors, outright breakage is the rarest outcome and the loudest one. The other two are quieter and, for a business, usually worse.

Disabled. The vendor switches the capability off on your live app on a published date. This is the honest failure mode: it has a deadline, it generates email, and it forces a decision. Webflow has done this twice in the period this site has been tracking, retiring Logic on 27 June 2025 and User Accounts on 29 January 2026, in both cases removing a capability from sites that were already using it.

Frozen. The app keeps serving traffic exactly as before, and you lose the ability to change it. Nothing alerts you, because nothing is broken. You find out on the day you open the editor to make an urgent change.

Grandfathered. Your app is exempted and keeps working, possibly forever. The cost is not paid today. It is paid the first time you want a feature that only exists on the new branch, at which point you are facing a migration you did not budget for.

The comparison

"Not documented" is not a compliment and it is not an accusation. It means the vendor publishes no deprecation policy, so you cannot know the answer before you need it.

Softr is the most transparent, and it shows you the frozen failure mode

Softr is the only builder here that publishes all three outcomes plainly, which makes it the best place to see what they actually feel like.

On grandfathering, Softr retired SMS sign-in and told existing users to do nothing at all.

Softr, verbatim: "On 13th June 2024, we discontinued SMS code as a sign-in method in Softr apps. Don't worry, if your apps have SMS sign-in, they'll continue to work for your users. No action is needed."

That is a good outcome and a clean notice. The same page explains the reason honestly, describing the feature as a technical debt that was blocking improvements to user management. New apps cannot have it. Existing apps keep it.

The larger case is Softr's app-version split. On 12 February 2025 the platform launched new authentication, headers, footers and utility pages. Apps built before that date are legacy apps, and Softr is unusually direct about the fact that you do not have to move.

Softr, verbatim: "Migrating your app from legacy has several benefits, but is totally optional - your app will continue to work whether you migrate or not!"

The caveats are where the real cost sits. Apps must be converted one at a time. Not every block is compatible with the new version. And if your signup collects extra information from users, Softr says the new version does not yet support that, so migrating may not be an option for you at all. Grandfathering is comfortable right up to the point where a new feature you want is only on the far side of a migration you cannot complete.

Then the frozen case, which is the single most useful sentence in this whole comparison.

Softr, verbatim: "A deprecated block will still work in your published app, but its settings can't be changed."

Read that again with an operational eye. The block renders. Customers use it. Analytics look normal. Nothing fails. And the configuration is sealed. There is no incident, no alert and no deadline, so nothing prompts you to act until the day you need to change a setting, which in practice is the day something has gone wrong elsewhere and you are in a hurry.

Bubble is the only one where the migration itself is one-way

Bubble replaced its linear version control with a branch-based system, and the transition has two paths. If version-test is your only development version, Bubble upgrades you automatically and version-test becomes your Main branch. If you have more than one custom version, you are asked to opt in. The warning attached to that opt-in is the thing to notice.

Bubble, verbatim: "The upgrade to the new version control system is permanent and cannot be undone."

Every other migration in this comparison has a way back. Softr saves a snapshot of the old app automatically. Lovable lets you revert the whole upgrade from version history. Bubble's is a door that locks behind you. That is not automatically wrong, and a branch-based model is genuinely better than what it replaced, but it belongs on the list of decisions you make deliberately rather than by clicking through a prompt.

Lovable moved its default stack and left old projects alone

Lovable's newest template is TanStack Start, which renders pages on the server. It became the default for new projects on 13 May 2026, and for new Enterprise projects on 22 June 2026. Projects built on the older React plus Vite stack were not touched.

Instead Lovable offers an in-place upgrade, and the design of it is the most careful in the group. The rewrite happens inside your existing project and carries your design, content and backend across. Your published site keeps serving the old version until you publish again, so the upgrade is staged rather than live. The whole thing can be reverted from version history. It is treated as ordinary build usage, so it consumes credits.

This is the grandfathered pattern done well: nothing was taken away, the new capability is real and the reason to move is stated in terms of what you gain. It is still a fork. A project that never upgrades is a project that cannot use features which require the new template, and that set only grows.

Webflow is the one that removes things, and the one that warns you properly

Webflow is the only builder here with a track record of disabling capability on live sites, and it is worth being precise about why that is not simply the worst position on the table. Both removals came with dated notices. A deadline is information. It is unpleasant information, but you can plan against it, and the alternative is a frozen block that tells you nothing.

Its developer tooling shows the same instinct at a smaller scale. Webflow CLI 2.0 renames several commands and raises the minimum Node.js version to 22.13.0.

Webflow, verbatim: "The commands from the previous version still work but emit deprecation warnings because they will be removed in a future version."

That is a textbook runway: the old path keeps working, it tells you it is going away, and the removal is signposted before it happens. The contrast with a silently frozen block is the whole argument of this article.

v0, Replit, Base44 and Bolt publish nothing to plan against

The remaining four have no published deprecation policy. That is not evidence of stability, and it should not be read as a clean bill of health.

v0 does show the fork pattern in miniature, and it is instructive because it is a new capability rather than a removal.

v0, verbatim: "Design mode is only available on chats that use the latest preview runtime, and only on the latest version of the chat."

Nothing was taken away from anyone. A new capability simply does not reach older work. That is the same shape as Lovable's template split and Softr's legacy apps, and it is the most common way these platforms actually move: not by removing, but by adding somewhere you are not.

For Replit, Base44 and Bolt.new, version history and Git integration give you a way to recover from changes you make. None of that helps with a change the platform makes, because the platform's decision is not in your commit log. The honest reading is that these four have short enough histories that the question has not been tested in public, and you should price that as unknown rather than as safe.

The part that inverts

The standing advice on this site, which holds on its own axis, is that owning the output protects you. On deprecation specifically, ownership does something narrower and more interesting than protection.

It does not remove the upgrade. A v0 project handed to you as a Next.js application has its own major versions, its own security support windows and its own breaking changes, and nobody at Vercel is going to do that work for you. Ownership moves the upgrade burden from the vendor's roadmap onto your backlog. That is more work, not less.

What ownership actually buys is the right to decline. Webflow could disable Logic on every site because Webflow runs every site. Nobody can disable your exported Next.js app, because nobody else is running it. You can stay on an old version past its support window and accept the risk, which is a bad idea and is nonetheless your decision to make. On the managed platforms, that decision is not available at any price.

Which gives the actual ranking on this axis, and it is not the usual one. The best position is not the most locked-in or the most portable. It is the one with the most published information, because every outcome here is survivable if you knew it was coming. Softr, which is one of the most managed platforms in the comparison and would place poorly on portability, is the strongest here, because it documents grandfathering, freezing and deprecation in plain language with dates. Bolt, Replit and Base44 would place well on portability and place worst here, because there is nothing to plan against.

And the failure mode to fear is not the one with a deadline attached. A disabled feature is loud, dated and budgeted. A frozen block is silent, and you meet it on your worst day. If you are auditing a builder on this axis, the question to ask is not "has this vendor removed anything", it is "when this vendor stops maintaining something, does my app tell me". The same reasoning applies to how changes reach your users in the first place, which is a separate question about pushing updates to a live app.

Verdict, September 2026

Softr ranks first on this axis, on documentation rather than on stability. It publishes dated notices, tells you plainly when no action is needed, and states the frozen-block behaviour that the others leave you to discover. That transparency is worth more than an unblemished record.

Webflow ranks second despite being the only builder that has removed live capability twice, because both removals were dated and announced, and its CLI deprecation warnings are the best-signposted runway here.

Bubble ranks third. The documentation is good and the automatic path is sensible, but the one-way upgrade is the sharpest irreversible step in the comparison and deserves to be a deliberate choice.

Lovable ranks fourth. The template migration is the best-engineered in the group, staged and revertible, and it loses ground only because it is a single documented instance rather than a policy.

v0 by Vercel, Replit, Base44 and Bolt.new are unranked here rather than ranked last. They publish no deprecation policy, so the correct assessment is that this is untested, not that it is safe.

If you remember one thing: check whether your builder tells you when it stops maintaining something you are using. Not whether it has broken anything yet.