Strava just pulled a Reddit on its developers. The lesson is about who owns your stack.

2026-06-02 · ~7 min read · Conor Dobbs

On June 1, 2026 Strava rewrote the rules of its developer program, and a lot of small, beloved projects went dark with it. If you built a self-hosted dashboard for your own runs, a niche analysis tool, or anything that pulled Strava data through a middle layer, you woke up to a different platform than the one you shipped on. The r/selfhosted thread about it climbed fast for a reason: this is the exact nightmare that community organizes its whole philosophy around.

I want to talk about what changed, but mostly I want to talk about the part that has nothing to do with Strava. Because if you build software for a living, the Strava story is a free lesson in a mistake that is very easy to make and very expensive to unwind: putting something you care about on top of an API you do not control.

What actually changed

The specifics, per Strava's own announcement and TechRepublic's coverage, are not subtle:

Building now costs money. Standard-tier developers need a paid Strava subscription, around $11.99 per month depending on region. New developers are affected immediately; existing active ones have until June 30 before the paywall lands.
Intermediary platforms are out. Apps that route Strava data through a third-party aggregation layer are no longer supported, because Strava says it cannot verify what happens to the data downstream.
Your data stops being shareable. Third-party apps can no longer display one user's data to other users. The data stays visible only to the person it belongs to.
The plumbing moved. The API base URL is changing to https://www.api-v3.strava.com, auth tokens must ride in request headers instead of form params, and the old deauthorize endpoint retires in 2027 in favor of a new revoke flow.

Some of that is reasonable hygiene. The header-based auth and the revoke endpoint are genuinely better practice. But the combination of a build-time paywall, a ban on intermediary platforms, and a hard stop on cross-user data display is enough to retire a large category of hobbyist and open-source apps overnight, especially the self-hosted ones that exist precisely because they route data their own way.

This is a rerun, and you have seen it before

Notebookcheck put it bluntly: Strava just pulled a Reddit on its developer community. The phrasing is earned. We have now watched this same movie enough times to recite the script. A platform opens an API to bootstrap an ecosystem. Developers show up and build genuinely good things on top of it. The platform grows, the API surface becomes a liability or a missed revenue line or an IPO-readiness checkbox, and the terms tighten. Reddit did it in 2023 and took Apollo down with it. Twitter did it. Now Strava, which multiple outlets tie to its upcoming IPO, is doing the 2026 edition.

To be fair to Strava, the company is not acting without cause. Its support documentation points at AI companies scraping platforms for training data, abuse through intermediary layers, and zero-code tools spinning up against the API. Developer applications reportedly jumped 448% year to date, and a lot of that traffic is not someone lovingly building a marathon tracker. From inside the company, tightening access reads as defense. From outside, it reads as a rug pull. Both things are true at once, and that is exactly why this keeps happening: the platform's incentives and your project's survival were never actually aligned. You just could not see the seam until it tore.

Renting versus owning

Here is the mental model I have landed on after getting burned by a deprecated API more than once. When you build on someone else's platform, ask one question: if they change the terms tomorrow, does my project survive? If the answer is no, you are not building. You are renting, and the landlord can raise the rent, change the locks, or convert the building to condos whenever it serves them.

Renting is not automatically wrong. Most useful software rents something, whether that is a cloud, a payment processor, or a data source. The mistake is renting the load-bearing wall and not noticing. The Strava apps that died were not careless; they just had no fallback for the one dependency that was the entire product. When that dependency moved, there was nothing underneath.

What I actually do about it now

You cannot self-host everything, and you should not try. But you can be deliberate about which dependencies you let become load-bearing. The checklist I run before building anything on a third-party API:

Own the part you cannot afford to lose. If the data or workflow is the heart of the product, get it onto infrastructure you control, even if that means a clunkier import instead of a slick live integration. A nightly export you own beats a real-time feed you rent when the feed gets revoked.
Abstract the vendor behind your own interface. Wrap the third-party API in a thin internal layer so that the day it changes, you patch one adapter instead of rewriting your whole app. This is boring and it is the single highest-leverage habit I have.
Read the terms like an adult, not a teenager clicking accept. Specifically look for what the platform reserves the right to change, what it says about commercial use, and whether intermediary or cross-user access is permitted. The Strava ban on both was foreseeable to anyone who read the direction of travel.
Monitor the dependencies you do not control. The teams that got hit hardest by Strava found out from an angry user, not from their own tooling. Put a watch on the endpoints and ToS pages that matter so a breaking change shows up as an alert you own, not a support ticket. This is half of why I built a dead-man's-switch monitor for my own jobs: the goal is to be the first to know when something I depend on stops behaving.
Have a graceful-degradation story. Decide in advance what your app does when the integration dies. Cached data, an export, a read-only mode, an honest banner. The apps that survive platform shifts are the ones that planned for the shift before it arrived.

The unglamorous takeaway

None of this is novel advice. It is the same lesson every API deprecation has been teaching for a decade, and we keep having to relearn it because building on a generous platform feels great right up until it does not. Strava is not a villain here, and the developers who built on it were not fools. The system just has a built-in expiration date that nobody marks on the calendar.

So mark it. Assume every external API you lean on will eventually tighten, price, or vanish, and build so that when it does, you are inconvenienced instead of erased. The difference between those two outcomes is decided long before the announcement, on the day you choose what to own and what to merely rent.