I’m building licensing for apps because payment providers shouldn’t own that layer.

I’m building Keylight: https://keylight.dev

It’s a licensing layer for developers shipping Mac apps outside the App Store and has SDKs for Rust, JS/TS, C#, C++ to easily plug them in as well.

The reason I started building it is simple: I kept seeing app licensing being treated as a side feature of payment providers.

Stripe, Paddle, Lemon Squeezy, Gumroad, Polar, etc. are great at payments. But your app usually needs to answer different questions:

Can this user run the app?
Is this license still valid?
How many devices are activated?
Can the app work offline?
Is the user on trial, paid, expired, or in grace period?
What happens if I switch payment provider later?

That last one is the part that bothered me most.

A lot of indie apps start with whatever provider is easiest. Then later they want to change pricing, move from one-time purchase to subscriptions, support multiple providers, or migrate away from a marketplace.

But by then, the licensing logic is already deeply coupled to the payment system.

Keylight separates the two.

Payment providers send events into Keylight. Keylight turns those events into license state. Your app only talks to Keylight through the SDK.

The goal is not to replace Stripe, Paddle, Lemon Squeezy, or any of them. The goal is to make licensing its own layer, so you can change payments later without rewriting how your app decides who has access.

Right now I’m focused on Apple apps first, especially indie Mac apps that want to sell directly.

Core pieces I’m building:

• License keys

• Device activations

• Offline validation

• Signed license leases

• Seat limits

• Feature flags

• Provider webhooks

• Swift, Rust + Tauri, JS/TS, C#, C++ SDKs

Still early, but the more I work on it, the more I think licensing should not live inside your payment provider.

Curious if other indie devs here have run into this.

Have you ever had to migrate licensing or payments after users were already paying?