To understate the obvious, there’s a big shift happening in how people think about software. After a decade of centralized platforms owning every layer of our digital lives, a growing number of developers and users are asking a simple question: what if I just ran this myself?

Parachord is a multi-source, pluggable, music player. Parachord is open source. The full source code is available under the MIT License. You can read it, build it, fork it, contribute to it. That was a deliberate choice from day one, and it reflects something bigger than a licensing preference. It reflects a belief about where software is heading.

The “Personal App” Movement

There’s a category of software emerging that doesn’t fit neatly into the traditional buckets of “consumer SaaS” or “self-hosted enterprise tool.” People are calling them personal apps — software designed to be yours. Not in the sense that you pay a subscription for access, but in the sense that you built it to solve a very specific and personal use case, you actually control how it works, what data it has, and what services it talks to.

Personal apps share a few common traits:

  • They aren’t designed to be businesses. The goal isn’t to raise money, make money or achieve a financial “exit”. They are designed to solve your personal pain points or improve/automate your own workflows.
  • They run on your machine. Your data stays local unless you explicitly choose to share it.
  • They’re open source or source-available. You can see what the code does. No black boxes.
  • They connect to services through your accounts. The app doesn’t sit in the middle. You bring your own credentials.
  • They’re composable. You pick the pieces you want and skip the rest.

This isn’t a rejection of cloud services. It’s a rethinking of who controls the relationship between you and those services.

Bring Your Own Key

The “bring your own key” (BYOK) pattern has been gaining traction across developer tools, AI wrappers, and now media applications. The idea is straightforward: instead of funneling all users through a single vendor API account (and absorbing the cost, liability, and lock - in that comes with it), the application lets each user authenticate with their own accounts and API keys. It also enables personal apps to exist when many companies are further restricting commercial access to their APIs.

In Parachord, this BYOK models shows up everywhere. When you connect Spotify, you’re not just logging in with your Spotify user account—you’re registering your own Spotify Developer app and using your own API credentials. That means Parachord isn’t designed as a third-party app requesting access on your behalf through some shared client ID. It’s your app, talking directly to Spotify’s API, with no middleman. The same goes for Apple Music, ChatGPT or Gemini for playlist generation through Shuffleupagus — those are all your API keys. Parachord never touches your credentials on our servers—because there are no servers in the middle.

This isn’t just a privacy nicety. It changes the economics and incentive structure of the software entirely:

  • No per-user API costs for to subsidize. I don’t need to limit features to paid tiers to cover third-party API or hosting bills - because there aren’t any (with the small exception of the smartlinks - which are currently running on a free Cloudflare plan).
  • No platform risk. If a service changes its API terms, your direct relationship with them is what matters—not ours.
  • No vendor lock-in. Parachord doesn’t own your playlists, your listening history, or your social graph. You do. Export anything as standard XSPF and take it wherever you want.
  • Honest software. When there’s no incentive to keep you locked in, the only thing that keeps you using the app is whether it’s actually good.

Why Open Source Matters Here

Open source isn’t just about transparency (though that matters). For a personal app, it’s structural. It’s the mechanism that ensures the app actually works the way the BYOK promise implies.

If Parachord were closed source, you’d have to take my word for it that your Spotify credentials aren’t being logged, that your listening data isn’t being shipped to a third party without your permission, that the plugin system isn’t doing something unexpected. Open source means you don’t have to trust—you can verify.

It also means the software can outlive any single maintainer’s interest. Parachord’s plugin system uses an open, documented SDK. If a music service launches tomorrow that we haven’t built a plugin for, you (or someone in the community) can build one. The architecture is designed for this. A .axe plugin file is just a JavaScript module with a declared interface. The barrier to contribution is intentionally low.

And it means that if you disagree with a decision I make—about defaults, about UI, about which services to prioritize—you have options beyond filing a complaint. Fork it. Patch it. Submit a PR. The code is yours.

The Rough Edges Are Part of the Deal

Let me be honest about something: I built this for me. I have very specific desires around enabling and fostering music data portability across the edges of the silos the commercial enterprises in the music space have created. I’m sharing it in the event others may share some of my pet peeves and desire to enable social media experiences that don’t require us to convince everyone to use the same music services we do. Parachord has been a one-person project up to this point. I can’t test every edge case on every platform, with every combination of plugins and accounts and system configurations. I spent a good amount of time testing fresh Mac installs on a 2020 Macbook running Tahoe - and it Works for Me™ - but I literally have no idea how it will do on any other platform. There are builds available for Windows and Linux but… 🤷‍♂️. I have no idea if they even open, let along work. If someone tries it, I’d love to know.

In the old model, that’s a dead end. You file a bug report, you wait, and maybe it gets fixed in six months if enough other people have the same issue. With a closed-source app from a small team, your only option is patience.

But here’s where open source and modern tooling change the equation. If something breaks for you, the code is right there. And you don’t need to be a seasoned developer to dig in. Tools like Claude can read a codebase, understand what a function is supposed to do, and help you figure out why it’s failing in your specific environment. Point an AI at the repo, describe your problem, and more often than not it can help you find the issue—and even draft a fix. That’s what I do every day.

This is genuinely new. A year or two ago, “the code is open source” was a nice-to-have for most users but a practical dead letter—reading someone else’s codebase is hard, and most people reasonably don’t want to spend their evening learning a new project’s architecture just to fix a bug. AI coding tools have collapsed that barrier. You don’t need to understand the entire resolution pipeline to fix a scrobbling issue in the Last.fm plugin. You just need to be able to describe what’s wrong, and let the AI navigate the code for you.

And the best part: when you fix something for yourself, that fix can go back upstream as a pull request. Your specific edge case—the one I never would have found on my own—becomes a fix for everyone. The community gets better because individuals solved their own problems. That’s the open source flywheel, but now it spins faster because the friction of contributing has dropped dramatically.

I’m not using “it’s open source” as an excuse for shipping broken software. I care about quality, I test what I can and I genuinely hope you have a magical first-run experience. But I’d rather ship something useful to a hundred people and let the five who hit edge cases help fix them, than wait until it’s perfect for everyone and ship to nobody.

The Bigger Picture

Parachord is a music player, but the pattern it represents is showing up everywhere. AI interfaces where you plug in your own model API keys. Note-taking apps that store everything in local Markdown files. Communication tools built on open protocols. Photo management that keeps your library on your own disk.

The thread connecting all of these: the application is a tool, not a platform. It helps you do something with services and data you already have, rather than asking you to hand everything over to a new intermediary.

This doesn’t mean every app should work this way. Plenty of software benefits from centralized infrastructure, shared state, and managed services. But for the category of tools that are fundamentally personal—where the data is yours, the accounts are yours, the preferences are yours—there’s a strong argument that the software should be yours too.

What This Means for Parachord

I’m building Parachord as a personal app because music listening is personal. Your taste, your library, your preferred sources, your friends, your desired social experiences around listening to music, your history—these aren’t things that should live inside someone else’s walled garden.

Being open source keeps us honest. The BYOK model keeps the economics simple. And the plugin architecture means Parachord can grow with the ecosystem rather than trying to own it.

If you want to brave an alpha release, you can read the alpha guide and download a release. If you want to dig into the code, it’s on GitHub. If you want to build a plugin, the SDK is documented and ready. If you want to just use the app and not think about any of this, that works too—it’s still just a music player that plays your music from wherever it lives. I don’t really know what my plans are for this from here - but I’m happy this exists again (RIP, Tomahawk) and that I get to use it daily. I hope you all get a chance to check it out and let me know what you think.

Thanks for reading,

J
(I’m @jherskowitz pretty much everywhere - except X)