Building a Modern Licensing System for AI Apps

AI apps have a licensing problem older software did not: the product is partly a piece of software you install and partly an ongoing stream of inference that costs money every time it runs. Those are two different things to charge for, and the most common mistake is letting them tangle into one system. This post is about untangling them and licensing the app cleanly.

Two things, not one

An AI desktop app contains two distinct commercial objects.

The first is the app itself — the interface, the workflow, the features, the thing the customer installs. That is software, and software is licensed: a customer is entitled to run it, on some number of devices, on some plan.

The second is AI usage — tokens through a hosted model, GPU minutes, calls to an inference endpoint. That is consumption, and consumption is metered: it accrues per use and is billed by volume.

These have fundamentally different shapes. A license is a yes/no entitlement that is cheap to verify and works offline. Metering is a running count that must live server-side because the usage happens against your costs. Trying to express both in one mechanism — a “license” that also tracks a token balance inline — produces something bad at both jobs.

The clean design keeps them apart: a signed license key entitles the customer to run the app, and a separate usage system handles inference. Get the first one right and the second is free to be whatever it needs to be.

Licensing the app

Licensing the app half of an AI product is the same problem as licensing any desktop app, with the same answer: a signed key the app verifies locally.

The customer pays through Stripe; a licensing layer mints a signed license and delivers it. The app ships with a public key and verifies the license at launch, confirming the customer is entitled to run the app. Whether a given action then costs tokens is a separate question your metering answers — but the license question is settled first, locally and instantly.

import KeylightSDK

await licensing.checkOnLaunch()

switch licensing.state {
case .licensed:     enableAppFeatures()   // entitled to run the app
case .trial(let d): showTrialBanner(daysLeft: d)
case .expired:      showRenewalPrompt()
case .invalid:      showActivationSheet()
}
// Token metering / usage limits are a separate system, layered on top.

Keeping the license offline-verifiable matters even for a cloud-backed AI app. The app should open and present its UI without waiting on a network round-trip. The network dependency belongs to the inference call the user explicitly triggers — not to the act of launching the app.

On-device models change the stakes

A fast-growing class of AI apps run the model on the device: local LLMs, on-device vision and audio, privacy-first assistants. The entire selling point is that nothing leaves the machine.

For these apps, online license validation is self-defeating. You have built a product whose value is that it needs no server, then bolted on a licensing check that does. On an air-gapped or offline machine — exactly where these customers run the app — that check cannot reach the server at all, forcing the same lose-lose: lock out a paying customer, or let the check be skipped entirely.

Offline license validation is the only model that fits. The signed license is verified locally, with no network call, so a fully on-device AI app stays fully on-device. Licensing introduces zero server dependency where the product deliberately has none. This is not a nice-to-have for on-device AI — it is a correctness requirement.

Scaling to a team

AI tools spread through teams fast. One person finds your app useful and within a month it is in everyone’s dock. Licensing has to keep up without a rewrite.

A licensing layer handles this through the device activation limit, which doubles as a seat count. A solo license allows a few activations; a team tier allows more. Each member activates the app on their machine against the shared license, and growing the team means moving up a tier — not rebuilding licensing.

The elegant part: the app license scales with seats, and your usage metering scales with consumption, independently. A ten-person team on a heavy-usage week and a ten-person team on a light week have the same license and different bills. That is exactly the separation you want — and you only get it if you kept the two systems apart from the start. The AI apps use case covers this further.

The rule

License the app with a signed key; meter the AI usage separately. The signed key gives you offline-capable, seat-scalable app licensing. Your metering gives you usage billing on its own terms. Keep them as two systems and both stay simple; merge them and both get worse.

If you are designing licensing for an AI product and hit a question worth a deeper post, send us your feedback.