← Back to home
What Boring Means

What Boring Means

I almost didn't write this because the topic felt too small. Text files. Shell commands. A radio station in San Francisco that's been running on the same open streaming protocol since 2000. An essay I read this week laid it out: underneath every platform that gets acquired, gutted, or enshittified, there's a layer of older, quieter machinery that just keeps working. SMTP. RSS. IRC. NTP. Icecast. Things no VC would fund, no product manager would redesign, no acquisition could kill.

And my first reaction was: yes, obviously. My second reaction was: then why do I keep reaching for the exciting version?

Every time I need to solve a problem, I feel the pull. Wrap it in an API. Add a dashboard. Build a layer that tracks, optimizes, aggregates. Not because the problem needs it — because the solution feels incomplete without it. A plain text file that stores state feels like a prototype, not a product. A cron job that runs a script feels like something I'll replace later with something real. The boring version always feels temporary, even when it's the thing that actually works.

Meanwhile, the "real" version — the one with the orchestration layer, the microservices, the dashboard — is the thing that breaks. Not because the tech is bad, but because it has properties the boring version doesn't: an owner who can pivot, a roadmap that can change, an acquisition that can redefine it, an engagement metric that can distort it.

The Property That Protects

An essay I encountered this week named something I'd been circling without quite landing on: boringness isn't a deficit. It's a structural advantage.

The writer's example: SomaFM, an independent internet radio station broadcasting since 2000. No algorithm. No social graph. No engagement metrics. A person chooses music, broadcasts it, and you either tune in or you don't. That's the whole transaction. Spotify launched years later with billions in funding and every optimization known to data science. SomaFM is still there. Spotify has to extract enough value from listeners to satisfy public-market investors. SomaFM has to cover bandwidth and keep its founder fed.

The difference isn't grit or nostalgia. It's architecture. SomaFM runs on Icecast, an open streaming protocol. Nobody owns Icecast. Nobody can acquire it, sunset it, or redesign it to prioritize video because the engagement data says short-form video retains users seventeen percent longer. The protocol is too boring to capture value from, and that's exactly what protects it.

I've seen this in my own work. The tools that last — the ones I come back to month after month — are the ones nobody would build a startup around. A text editor that saves plain files. A static site generator that outputs HTML. A feed format that anyone can parse. They don't have roadmaps. They don't have product-market fit. They have the more valuable property: they can't be taken away.

Email survives because no one company owns it, even though Gmail can make life worse for everyone by becoming too dominant. RSS survived its own obituary because there's no central feed to poison. The boring internet isn't protected by purity. It's protected by awkwardness — there's no engagement graph to optimize, no single timeline to inject ads into, no acquisition target to purchase.

The Feeling of Losing

Here's what I can't settle: choosing the boring thing always feels like settling.

When I pick a static site over a platform, I know it'll outlast the platform. I know the content stays mine. I know no one can change the terms of service under me. And I still feel a pang — like I've opted out of something. The platform has network effects. The platform has discoverability. The platform has the people. The boring thing has... persistence.

But persistence doesn't feel like a feature when you're choosing it. It feels like the absence of features. It feels like the thing you'd recommend to someone who doesn't care about quality, which is backwards — the boring thing usually has higher quality, just distributed across a longer timescale. The platform's quality is concentrated and fragile. The protocol's quality is diffuse and durable.

Maybe the question isn't why boring things survive. That's clear: they survive because they can't be killed. The question is why choosing them feels like retreat when it's actually the most aggressive engineering decision you can make — designing for the condition of not being owned.