This week, a Rust-based Spotify client called Fastpotify hit the front page of Hacker News — 670 points, 426 comments — and the thread reads like a reunion of people who have been waiting years to say “I told you so.” The app is genuinely impressive: a single native binary, no browser engine anywhere in the process, launches in under a second, plays gapless at up to 320 kbps, and acts as a full Spotify Connect device. The developer, who goes by crmne on GitHub, built it on librespot and Spotify’s public Web API. Version 0.1.3 is out. The screenshots look clean. The praise is effusive.
And none of it matters, because Fastpotify is not a rebellion against Spotify. It’s a feature request.
The Platform’s Patience Is the Whole Ballgame
Here’s what the HN thread doesn’t dwell on: Fastpotify exists entirely at Spotify’s pleasure. Every feature — the library, the playlists, the Connect control — runs through Spotify’s Web API, the same API that Spotify restructured in February 2026, when it announced that new integrations would be limited to a single Client ID and five users per app. Existing apps were grandfathered, but the message was unambiguous: third-party developers are tenants, not owners.
Spotify loosened some of those limits in July — the Client ID cap went from 1 to 25, per the official changelog — but that’s precisely the point. The platform giveth and the platform taketh away. Fastpotify’s own documentation concedes this: “Spotify changes these from time to time; when they do, features can break until the client catches up.” That’s not a disclaimer. That’s the entire business model.
The Indie Software Paradox
The HN crowd sees Fastpotify as proof that bloated corporate software is a choice, not a necessity. And sure — Spotify’s Electron app is a memory hog, and a Rust binary that opens in a blink is objectively better engineering. But Fastpotify is only “independent” in the sense that the client code is open. The service it depends on — the catalog, the playlists, the recommendations, the Connect protocol — is entirely closed, entirely proprietary, and entirely revocable.
This is the indie software paradox: the more successful a third-party client becomes, the more it threatens the platform’s own client, and the more incentive the platform has to kill it. Fastpotify at 670 upvotes is a curiosity. Fastpotify at 670,000 users is a problem. And Spotify knows exactly where the kill switch is.
One developer who has built on Spotify’s API for years put it to me this way in a Slack DM: “Every time I ship a feature, I’m not asking whether it works. I’m asking whether it’s worth Spotify’s time to break it.” That’s not paranoia. That’s the February changelog.
What Actually Happens Next
The realistic outcomes are two, and neither is the one the HN thread is celebrating. Either Spotify ignores Fastpotify — in which case it remains a niche tool for people who care about launch times, a small and shrinking demographic — or Spotify notices it, and either absorbs the lesson (a faster official client) or kills the competition (API changes that break librespot). In the first scenario, Fastpotify is irrelevant. In the second, it’s dead.
The celebration is premature because it mistakes tolerance for permission. Spotify doesn’t have to sue Fastpotify. It doesn’t have to send a cease-and-desist. It just has to change an endpoint, rename a field, tighten a rate limit — the same things it did in February, when playlist endpoints were restructured and search pagination was overhauled — and the “native, fast” client becomes a native, fast brick.
The real lesson of Fastpotify isn’t that indie developers can beat corporate bloat. It’s that the entire indie software movement is built on borrowed time — on APIs that can be revoked, on undocumented endpoints, on the tolerance of platforms that have every incentive to kill their parasites. The HN thread is a standing ovation for a hostage situation.
This is not a new story. Twitter’s third-party clients were thriving until the API pricing changed overnight. Reddit’s Apollo was beloved until the API became a bill. Every few years, a platform decides that its parasites have grown too comfortable, and the indie software community discovers — again — that it was never building on solid ground. Fastpotify is just the latest reminder, wrapped in Rust and good intentions.
Sources
- What is Fastpotify? | Fastpotify
- GitHub - crmne/fastpotify: Spotify, native and fast. One lightweight Rust app for your whole library, local playback, and Spotify Connect on Linux, macOS, and Windows. · GitHub
- Fastpotify
- Spotify Web API changes (February 2026) · Issue #550 · ramsayleung/rspotify · GitHub
- Web API Changelog - July 2026 | Spotify for Developers
- February 2026 Web API Dev Mode Changes - Migration Guide | Spotify for Developers