Built on Sand: What Happens When the API Dies and Your App Goes With It

In March 2023, Twitter killed free API access overnight. Not with a long deprecation window or a generous migration path — with a blog post and a countdown. Hundreds of third-party apps, some with years of development behind them, stopped working within days. Tweetbot. Twitterrific. A constellation of indie tools that, for a lot of users, were Twitter. Gone.

This wasn't new. It was just louder than usual.

The API graveyard is a real place, and it's been filling up for years. Google Reader's API. Vine's developer tools. Mailchimp's legacy endpoints. Parse, the mobile backend that Facebook acquired and then shut down with 18 months notice, leaving thousands of apps scrambling. Instagram's API, progressively strangled from 2016 onward until the rich ecosystem of third-party clients was basically rubble.

Every one of these shutdowns followed the same script. Platform grows. Developers build on it, often because the platform encouraged them to. Platform matures, or pivots, or gets acquired, or decides the ecosystem is a liability. API gets deprecated. Developers eat the loss.

The Deal You Didn't Know You Made

When you build on someone else's API, you're entering into an agreement that's almost entirely unwritten and almost entirely in their favor. The terms of service will tell you the platform can change or terminate access at any time. What they won't tell you is that they will — and that when they do, the community you built, the users you served, and the revenue you depended on will have no legal recourse and approximately zero leverage.

Jordan has been building indie software tools for about eight years, mostly productivity apps with small but loyal user bases. He's been through two API shutdowns that directly affected his products. "The second time it happened, I wasn't even angry," he says. "I was just embarrassed that I'd trusted them again."

The experience changed how he builds. His last three tools have no external API dependencies at all. "If your app needs someone else's server to run, you don't have an app. You have a client for someone else's app. There's a difference."

That distinction — between a tool you own and a client for someone else's infrastructure — is the fault line the offline-first movement is built on.

What "Offline-First" Actually Means

The term gets thrown around loosely, but in its most useful form, offline-first means the application works completely without a network connection, and syncing (if it happens at all) is an enhancement rather than a requirement. Your data lives on your device. Processing happens locally. The app doesn't phone home to do its job.

This is not a new idea. It's actually how software worked for most of computing history. The cloud-first model is the newcomer. But somewhere in the 2010s, "requires internet connection" stopped being a red flag on a software listing and became the default expectation. We normalized dependency.

The developers building offline-first alternatives today are, in a sense, just recovering that ground. Obsidian stores your notes as plain text files on your own machine. Heynote runs locally with no account required. Datasette can run entirely on your laptop. These aren't compromises — for many users, they're objectively better than the cloud-dependent alternatives because they're faster, more private, and immune to the shutdown problem.

The Real Cost of Platform Dependency

The API deprecation problem isn't just a developer headache. It flows downstream to users who never wrote a line of code.

When a third-party Twitter client dies, the person who loses isn't the developer. It's the user with low vision who relied on that client's accessibility features. It's the person who'd spent years curating a feed that actually worked for them. It's the community that formed around a particular client's culture. The developer moves on to the next project. The users just lose something they counted on.

This is the hidden externality of building on rented infrastructure. The risk gets distributed to everyone except the platform that created it.

Alex, who builds tools for journalists and researchers, started auditing his dependencies after a data provider he'd integrated quietly changed pricing, making his tool economically unviable overnight. "I went through everything and asked: if this service disappeared tomorrow, what breaks?" The answer was uncomfortable. "Almost everything broke."

He spent the next six months rebuilding his core tools to be self-hostable. Users can now run them on their own servers or locally. "I lost some users who didn't want to deal with that complexity. I kept the users who actually cared about the work. That was the right trade."

The Structural Problem No One Wants to Say Out Loud

Here's the thing the tech industry would prefer you not dwell on: the API ecosystem, as it exists, is designed to create dependency, not enable it. Platforms open APIs to attract developers who build value on top of the platform, which attracts users, which grows the platform. Once the platform is big enough, the developers are no longer necessary — and may in fact be competition.

This isn't cynicism. It's the documented pattern. Twitter killed third-party clients because Twitter wanted ad revenue from its own apps. Instagram clamped down because Facebook wanted to own the user relationship. The developer ecosystem was a ladder the platforms climbed and then kicked away.

Building offline-first isn't just a technical decision. It's a refusal to participate in that dynamic. It's saying: my tool will not be a dependency of yours. My users will not be your users. When you decide to change direction, my work won't go with you.

Where This Goes

The offline-first movement is small but it's coherent. There's a growing body of tooling — CRDTs for conflict-free local sync, SQLite for embedded databases, Tauri and Electron for local-first desktop apps — that makes building this way easier than it's ever been. The technical barriers are lower. The philosophical case has never been stronger.

The API graveyard will keep filling. That's not pessimism — it's pattern recognition. Every platform that opens an ecosystem eventually closes it. The only question is whether developers keep building on sand or start pouring their own foundations.

Some of them already have. The rest are one deprecation notice away from joining them.