Originally published on the Keylight blog.
"Should I charge once or charge monthly?" is one of the first real decisions an indie app faces, and it is usually answered by copying whoever the founder admires rather than by what fits the product. Both models are legitimate. This post lays out when each one actually makes sense, the honest tradeoffs, and how Keylight models perpetual keys and renewing subscriptions so the licensing follows your pricing instead of constraining it.
The two models, defined
A one-time (perpetual) license is a single payment for a license that does not expire. The customer owns that version β and usually some agreed window of updates β forever. Think of the classic "buy version 3, use it as long as you like" desktop app.
A subscription license is a recurring payment for continued access. The license is valid while the customer keeps paying; stop paying and access ends or degrades. The recurring revenue funds ongoing development and any server-side costs the app carries.
The distinction is not about the dollar amount β it is about what the customer is buying: ownership of a thing, or ongoing access to a service. Get that framing right and the model usually picks itself.
When a one-time license is the right call
A perpetual license fits when your app is a tool the customer owns and runs locally, with low ongoing cost to you per user. A focused Mac utility, an audio plugin, a developer tool that does its job on the user's machine β these have little marginal server cost, so charging rent for access is hard to justify and customers feel it.
One-time pricing also builds trust. There is no metering, no "what happens if I stop paying," no fear of being locked out of work they already did. For tools people depend on, that ownership feeling is a genuine selling point, and it is exactly the kind of no-value-extraction stance that earns goodwill with developers and power users.
The tradeoff is honest: revenue is lumpy and front-loaded. You get paid once per customer, so growth depends on continually reaching new buyers, and a quiet month is a lean month. The usual answer is paid major upgrades β version 4 is a new purchase β which we will come back to.
When a subscription is the right call
A subscription fits when your app is genuinely a service, not just a binary. If you run sync infrastructure, host an API, ship inference that costs you per call, or provide content and models that need continuous updates, those costs recur β so the revenue should too. Charging once for a product that costs you every month to keep running is how indie apps quietly go underwater.
Subscriptions also suit apps under continuous, fast development, where customers are paying for an evolving product rather than a fixed version. The recurring revenue is what lets a solo developer keep working on it full-time.
The tradeoff, again honestly: subscriptions ask more of the customer and carry an implicit promise. People resist renting software that feels like it should be owned, and a subscription obligates you to keep delivering β let development stall and churn follows fast. Subscribe-to-use should map to a real, ongoing service. If you are reaching for a subscription only because the recurring revenue looks nicer on a chart, that is the SaaS playbook pointed at a product that does not need it, and customers can tell.
How Keylight models each
The point of a good licensing layer is that it expresses your pricing rather than dictating it. Both models are the same signed lease with a different expiry.
A perpetual license is a lease with expiresAt set to null. It verifies offline forever; nothing time-bound ever ends it. The only thing that revokes it is an explicit action β most often a refund, which marks the key revoked so the app rejects it on the next revalidation. This is the model behind perpetual licenses.
A subscription license is a lease whose expiresAt is tied to the Stripe billing period. When Stripe reports a renewal, Keylight reissues the lease with a later expiry; the app picks up the extension on its next revalidation. If the subscription lapses, the lease simply expires β and Keylight's default is to drop the customer to a free or expired state, not to hard-lock the app, so a failed card does not lock someone out of their own work mid-task.
Because both are just leases, switching models or running both is a configuration choice, not a re-architecture. Your app reads the same license state machine either way.
The hybrid most indie apps actually want
In practice many indie apps want neither pure model β they want a perpetual license with a bounded updates window. The customer pays once, owns the version they bought forever, and gets updates for, say, a year; after that the app keeps working indefinitely, but new versions are a fresh purchase. It is the "fair perpetual" model: customers are never locked out of what they paid for, and you still have a recurring reason for them to pay again.
This maps cleanly onto leases. The perpetual entitlement never expires; the updates window is its own expiry your app checks before offering a newer build. The customer's app never stops working β only the "free updates" entitlement lapses. You get a renewal motion without the rented-software resentment a hard subscription can create. For a deeper treatment of the subscription mechanics specifically β renewals, upgrades, and downgrades β see subscription licensing for Mac apps.
There is no universally correct answer, only a fit. Own-it tools lean one-time; real services lean subscription; a lot of indie apps are happiest in the fair-perpetual middle. Decide based on what the customer is actually buying and what the app costs you to run β and let the licensing layer express that decision rather than push you toward whichever model bills more. If you are weighing this for your own app, send us your feedback and we'll think it through with you.
FAQ
Is a one-time license or a subscription better for an indie app?
Neither is universally better. One-time fits focused tools customers buy and own; subscriptions fit apps with ongoing server costs or continuous development. Many indie apps land on a hybrid: a perpetual license with a bounded window of free updates.
How does Keylight model a perpetual license?
As a lease with no expiry β the expiresAt field is null. The signed lease verifies offline forever; the only thing that ends it is an explicit revocation, such as after a refund.
How does Keylight model a subscription?
The lease carries an expiry tied to the Stripe subscription period. On renewal the lease is reissued with a later expiry; if the subscription lapses, the lease expires and the app moves to an expired or free state rather than hard-locking.
