1.4

When the Platform Removes Something You Depend On

Rented Ground: What You Actually Own When You Own a Website

Every major website platform is being rebuilt around code and AI agents. Four questions decide whether that’s your problem or someone else’s.

Articles in this series

The risk people worry about isn’t the one that happens

Ask an owner what worries them about their website platform and they’ll usually say something about the company going under.

That’s not what happens. What happens is smaller and far more common: the company carries on perfectly well, and quietly stops supporting one thing you’d built your business on.

Two recent examples, stated plainly

Webflow retired two native features in eighteen months.

Logic, its automation tool, was disabled on 27 June 2025. Existing flows stopped running. Forms that had been connected to them reverted to ordinary forms. The recommended replacements were Zapier and Make.

User Accounts — originally launched as Memberships — was disabled on 29 January 2026. Sites using it lost login functionality and the associated APIs. The recommended replacements were Memberstack and Outseta.

Both were announced well in advance, both came with migration guidance and partner discounts, and both landed on the date given. As deprecations go, this was handled decently.

It was still, if you’d built a members’ area on it, a rebuild you didn’t ask for and hadn’t budgeted.

And this isn’t a Webflow habit worth singling out. The WordPress plugin ecosystem abandons things constantly, usually with no notice at all because there’s no company to give any. Google has retired so many of its own products that people maintain lists of them. Every platform does this. The only variable is how much warning you get.

The question that predicts it

Here’s the pattern, and once you see it the deprecations stop being surprising.

Vendors keep what makes them money and shed what doesn’t.

Webflow’s business is design, content management and hosting. Automation and authentication were adjacent products competing against companies whose entire existence was automation and authentication. They were never going to win those fights, and the engineering attention was better spent elsewhere. Retiring them was, from where they sat, obviously right.

Which gives you a usable test. For every feature your website depends on, ask:

Is this the vendor’s core business, or a convenience they bundled in?

If it’s core, it’s safe — they’d have to change what the company is to remove it. If it’s a bundled convenience, particularly one competing against dedicated products, it’s exposed. Not doomed. Exposed.

Four questions to grade a dependency

Work through these for anything your site depends on:

  1. Is it what the vendor sells, or a bonus? If you couldn’t imagine it appearing on their pricing page as a headline, it’s a bonus.
  2. Is there a healthy market of dedicated competitors doing it better? If yes, that’s where the vendor will eventually point you.
  3. How much of it is in the marketing? Features being actively promoted this year are safe this year. Features that have gone quiet — no updates, no roadmap mentions, absent from launch announcements — have usually already lost the internal argument.
  4. If it vanished with twelve months’ notice, what would it cost you? This is the only number that turns the risk into a decision.

Your dependency register

Fifteen minutes, once a year. A table with a row for everything your website relies on:

| Feature | What it does for us | Core to vendor? | If removed, replacement | Cost to switch | Notice we would expect | | :--- | :--- | :--- | :--- | :--- | :--- | | CMS | Blog, case studies | Yes | n/a | n/a | n/a | | Forms | All enquiries | Yes | n/a | n/a | n/a | | Member login | Gated pricing for trade customers | **No** | Memberstack / Outseta | [[£???]] | 6-12 months | | Automation | Routes enquiries to CRM | **No** | Zapier / Make | [[£???]] | 6-12 months | | Analytics | Traffic reporting | Partly | Independent tool | Low | Unknown |

The bold rows are your exposure. Everything else is noise.

If a bold row also generates revenue, that’s the one to deal with — not by panicking, but by deciding now, calmly, whether you’d rather move it to a dedicated provider on your own schedule than the vendor’s.

The rule

Don’t build a revenue-critical function on a bundled feature that isn’t the vendor’s core product.

Bundled features are excellent for things that would be annoying to lose and fine to rebuild. They’re a poor foundation for anything that takes money, holds customer identity, or would stop your business if it stopped.

That’s not a criticism of the vendors. Bundling genuinely useful things is how platforms attract people, and it usually works out. It’s just that the decision to keep or kill it will be made on their commercial logic, not on how much you were relying on it.

What to do this week

Nothing dramatic. Fill in the register. If a bold row is carrying revenue, get a quote for the standalone replacement so you know the number.

Knowing the number is most of the work. It converts a vague unease into a line you can either accept or act on, and either is better than the shrug.

Deprecation dates verified against Webflow’s help centre, 13 August 2026.

Back to Rented Ground
→ Next: Who Is Allowed to Change Your Website Now?

TL;DR

The realistic risk isn’t your platform failing — it’s one feature your business runs on being retired and handed to a third party with a date attached. You can work out in advance which of your dependencies are exposed, using one question about the vendor’s business model.

Mark Thurman