When I was designing Ludra, I had to decide how to handle third-party APIs — Steam, IGDB, YouTube. The obvious approach: manage the keys myself, build a backend, issue tokens to users. That’s what every tutorial tells you to do. That’s what every production app does.

I did the other thing instead. I made the user bring their own keys.

The case against centralised key management

When you manage API keys for your users, you are taking on obligations. You need a backend. You need a database. You need authentication. You need rate limiting. You need to monitor costs. You need to worry about abuse. You need to worry about breaches.

For a solo developer building a free app with no revenue, this is an enormous amount of infrastructure to justify.

But more importantly: you’ve now become a data custodian. Your users’ usage patterns flow through your systems. Even if you never look at them, they’re there. Even if you have good intentions, you’ve created a surface area that could be compromised.

The alternative is to simply not be in the middle.

BYOK in practice

Bring Your Own Key means the user authenticates directly with the third-party service. The keys are stored locally, on their device, using the platform’s secure storage. When the app makes an API call, it goes from their device to the service. My server — which doesn’t exist — sees nothing.

The tradeoff is onboarding friction. Getting a Steam API key is easy. Getting an IGDB key requires creating a Twitch account and enabling 2FA. Getting a YouTube key means navigating Google Cloud Console, which is a maze even for developers.

The solution to this is documentation. Not brilliant architecture — just clear, patient, step-by-step instructions that treat the user like an intelligent adult who can follow a process.

I wrote that documentation. It’s three pages. It explains every step, includes direct links, and warns about the specific things that trip people up (Twitch requiring 2FA before developer access, Google Cloud’s OAuth consent screen, Steam’s public profile requirement).

What you give up

You can’t do server-side personalisation. You can’t aggregate data across users. You can’t build features that require knowing what all users are doing.

For a personal utility app, none of those things matter.

What you get

Zero backend costs. Zero data responsibility. Zero risk of a breach exposing your users’ keys. An app that keeps working if you get hit by a bus. Infrastructure that scales to one million users as easily as one.

And an honest answer when someone asks: what data do you collect?

Nothing. We built it that way on purpose.