Most licensing advice is written for companies with a legal department and a sales team. If you are one person or three, the interesting question is not which model maximises revenue in theory. It is which one you can actually operate without licensing becoming your second job.
So here are the four models with that constraint applied, and then the part almost nobody writes down honestly: what enforcement is worth.
Perpetual, with paid major versions
The buyer pays once and owns that version forever. Version 3 is a new purchase.
Operationally the cheapest. One key, no expiry, no renewal billing, no dunning emails, no card-declined flow. A licence check is a signature verification you can write in an afternoon.
The problem is the sawtooth. Revenue arrives around releases and decays between them, which means your income depends on shipping something big enough to charge for on a schedule you control less than you think. Two quiet quarters is a cashflow problem, not a marketing problem.
Pick it when your product is a tool rather than a service, your users are individuals rather than companies, and you would rather have a smaller predictable maintenance load than a larger predictable income.
Subscription
Recurring payment for continued access.
The revenue is better and the operation is heavier. You are now running billing infrastructure, handling failed payments, answering cancellation requests, and deciding what happens to someone's data and access when they stop paying. That last one is a product design problem with legal edges.
The credibility test: if you stopped working entirely, would a subscriber still receive something next month? Sync, hosting, a maintained dataset, a model that improves — those justify recurring payment. Access to a binary you already shipped does not, and users say so loudly, particularly on macOS.
The honest middle is a perpetual fallback: subscribe for updates, and if you cancel you keep the last version you paid for. It converts worse than a pure subscription and generates a fraction of the resentment.
Seat-based
Price per user in an organisation.
This is the only model on the list whose buyer is a procurement department, and that changes everything about what you sell. Companies do not mind seat counts. They mind invoices, purchase orders, SSO, and having someone to call.
The trap is counting. Defining a seat is easy; enforcing it is where indie tools drown. Named users, concurrent users, machines, or an honour-system count you invoice against — the last one is not a cop-out, and for a small tool it is usually correct.
Pick it when you already have organisations using your tool informally. If you do not, adding seats does not create them.
Usage-based
Price per unit of the thing the software does.
Aligns beautifully and bills terribly. It is the fairest model when the value genuinely scales with volume, and it requires metering you can defend, an invoice that explains itself, and a customer willing to accept a bill they cannot predict.
Pick it when your costs scale with usage too. If they do not, you are adding billing complexity to protect a margin you were not losing.
The enforcement question
Here is the part worth internalising, because it determines how much of your life licensing consumes.
Every licence system is defeatable. Yours will be. The question is only whether it is defeated by an expert once and posted, or by an ordinary user casually. Those are the two outcomes, and the effort required to move between them is enormous.
The practical position most successful small vendors land on:
- Make honesty easy. Fast purchase, immediate key delivery, licence works offline, transfers between machines without a support ticket.
- Make casual copying slightly inconvenient. A signed key tied to an email address is enough. Not because it stops anyone determined, but because it makes the copy feel like a copy.
- Stop there. Hardware fingerprinting, online activation, phone-home checks and dongles all punish paying customers reliably and pirates briefly. Every one of them generates support load from people who did pay.
- Assume the people bypassing it were never going to buy. Not always true, but true enough that optimising against them costs more than it recovers.
Aggressive DRM in a small product is almost always a bad trade. It converts a revenue problem into an engineering problem and a support problem, and the revenue problem stays.
If licensing is the wrong shape entirely
Sometimes the answer is that your product cannot support a licence, and the honest response is a different revenue model rather than a cleverer key system.
A free utility with a wide install base and no professional segment has nothing to gate. For those, what free Windows software can actually earn covers the options that do not require withholding anything, and what apps make per download puts the numbers side by side.
Choosing, in four questions
- Is your buyer a person or a company? Company means seats and invoices.
- Would a subscriber get something next month if you stopped working? No means perpetual.
- Do your costs scale with their usage? Yes means usage-based is at least worth modelling.
- How many hours a month can you spend on billing and licence support? Be honest, then pick the model that fits that number rather than the one with the best revenue chart.
Question 4 is the one people answer last and should answer first.
Your first 100 devices go live today.
No sales call, no approval to start. Sign up, drop the SDK in, and watch the first device appear in your dashboard.
Create your free accountFrequently asked
Which licensing model is best for a small software business?
Perpetual licensing with paid major versions is usually the best fit for one to three people, because it has the lowest operational overhead: one key, no expiry, no recurring billing and no failed-payment handling. Subscriptions produce better revenue but add billing infrastructure, cancellation handling and access-expiry decisions. Seat-based pricing only makes sense if organisations already use your tool, and usage-based pricing is worth considering mainly when your own costs scale with usage too.
Is a subscription or a one-time purchase better for desktop software?
It depends on whether there is ongoing value to pay for. A useful test is whether a subscriber would still receive something next month if development stopped entirely — sync, hosting or a maintained dataset would, access to an already-shipped binary would not. Desktop users, particularly on macOS, react badly to subscriptions for the software itself. A common middle ground is subscribing for updates while keeping the last version paid for if the subscription lapses.
How much licence enforcement is worth building?
A signed key tied to an email address, verified offline, is enough for almost every small product. Every licence system is defeatable, and the meaningful difference is only whether it is broken once by an expert or casually by ordinary users — closing that gap takes enormous effort. Hardware fingerprinting, online activation and phone-home checks reliably generate support load from paying customers while delaying determined copying briefly, which is a poor trade for a small team.
How do I define a seat for seat-based pricing?
The options are named users, concurrent users, or machines, and each needs enforcement you are willing to maintain. For a small tool, an honour-system count that the customer declares and you invoice against is usually the right answer rather than a compromise: organisations that buy software have procurement processes and generally do not want to be out of compliance, and building enforcement machinery for them costs more than the leakage it prevents.
What if my software cannot be licensed at all?
That is a common position for free utilities with wide install bases and no professional segment — there is nothing to put behind a paywall without making the free version deliberately worse. The realistic alternatives are sponsorship, donations, a paid companion product, or bandwidth sharing, which pays for users who opt in to relaying a capped share of unused connection capacity without gating any feature. Which fits depends mostly on whether your audience is specific enough to sell to a sponsor.