Build vs buy: software licensing for .NET (2026)

Build it yourself only if your licensing needs are genuinely trivial and will stay that way; buy it the moment you need seats, revocation, trials, or a customer portal — because at that point you are not adding a feature, you are building and running a backend product that has nothing to do with what your customers actually pay you for. This guide walks through the real, itemized cost of rolling your own .NET licensing so you can make that call with eyes open, and it is honest about the cases where DIY is the right answer.

The part everyone underestimates

Most developers picture licensing as “generate a key, check the key.” That part genuinely is easy. .NET ships System.Security.Cryptography.RSA in the box; you can sign a blob of JSON on a server and verify it in your client in an afternoon. If that were the whole job, nobody would sell licensing.

The job is everything wrapped around that signature. Below is the checklist that separates a demo from something you can actually ship to paying customers — and each line is a decision you own forever once you build it.

Signing keys and key management

You need an asymmetric key pair: a private key that signs licenses server-side and a public key your app embeds to verify them. Fine. Now answer the operational questions. Where does the private key live? How is it encrypted at rest? Who can access it? What happens when it leaks — can you rotate it without bricking every already-shipped copy of your app? If you sell to multiple customer segments or resell through partners, do they share one key (a single point of catastrophic failure) or get isolated keys you now have to manage at scale?

A serious answer looks like per-customer key isolation with the private key encrypted at rest and a documented rotation path where an old and new key both validate during the transition. That is not a hard concept, but it is real, security-sensitive code you now maintain.

A license file format you won’t regret

You have to decide what a license is on the wire: the fields (licensee, product, tier, seats, expiry, entitlements), the serialization, and how the signature is attached. Get this wrong early and you will be maintaining format shims for years, because you can never break a format that is already deployed in customers’ installs. Versioning a signed format that both old and new clients accept is its own small project.

Node-locking that doesn’t punish honest users

Binding a license to a machine sounds simple until you build the fingerprint. Hash too many hardware attributes and a customer who swaps a NIC or upgrades a disk gets locked out and files a support ticket. Hash too few and the lock is trivially bypassed. You need a stable fingerprint with tolerance — enough drift allowed that ordinary hardware changes don’t trip it — and a documented way to override which components identify a machine for unusual environments like VMs and CI.

Seat counting, which forces you onto a server

Here is the wall DIY hits hardest. You cannot count seats offline. A purely client-side check has no idea how many other machines are running the same key. The moment you promise “3 seats,” you need a server that records activations, enforces the cap atomically (no race that lets ten machines grab three seats), makes re-activating an already-bound machine idempotent, and lets a customer free a seat when they retire a device. That is a stateful, concurrent, always-on service — the exact thing “just check a key” was supposed to avoid.

Offline validation and fail-closed behavior

Plenty of software must run air-gapped or through network outages, so you also need offline validation: verify the signature, product match, node-lock, and expiry with no network call. And you need it to fail closed — any verification problem (bad signature, wrong product, expiry, a clock rolled backward to cheat a trial) must resolve to the unlicensed state rather than throwing an unhandled exception or, worse, failing open and unlocking everything. Getting fail-closed semantics right everywhere is fiddly, and it is the difference between a license check and a suggestion.

Revocation that reaches offline clients

A refunded, charged-back, or leaked key has to die. Online, that is a server flag checked on the next activation refresh. Offline, it is harder: you need a signed revocation list you can ship with an update so even a disconnected client honors it. Build both paths, or your only remedy for a leaked key is a new release.

Trials, without handing out free forever

Self-service trials mean minting time-limited keys on demand — and immediately dealing with abuse. One trial per email per product, idempotent so a refresh doesn’t reset the clock, auto-expiring, revocable, and ideally converting to a paid license with no reinstall. Every one of those is a rule you have to design and enforce.

A customer portal, or a support queue

Finally, the part that never makes the estimate: customers will want to see their keys, move a seat between machines, and re-download a license file without emailing you. Skip the portal and every one of those becomes a manual support ticket. Build the portal and you have a small authenticated web app to maintain on top of everything above.

So when is building it yourself the right call?

DIY is genuinely fine when all of these hold: you sell a single perpetual license with no seat limit, you never need to revoke a key in the field, you don’t offer trials or a customer portal, and you are comfortable owning security-sensitive crypto code indefinitely. A signed license file verified offline against an embedded public key is a reasonable weekend build under those constraints, and you should not pay a subscription to avoid it.

The calculus flips the instant any of those assumptions breaks — and for most commercial software, at least one breaks in year one. Subscriptions need expiry and renewal. Teams need seats. Growth needs trials. Support load forces a portal. Once you are building three or four of those boxes, you are running a licensing backend, and the maintenance never ends.

The buy option: what a licensing service gives you

Keyright is the licensing service we build at Delta1 Labs, and it exists precisely to hand you that whole checklist as infrastructure. It issues cryptographically signed offline license files and short-lived online activation leases, so you get air-gapped validation and server-enforced seats from the same system. Every tenant gets its own isolated RSA signing key, with the private half stored AES-256-GCM-encrypted server-side and never exposed. Node-locking uses a fingerprint with built-in tolerance. Revocation is one click and reaches both online clients (next refresh) and offline ones (a signed revocation list you ship). Entitlements let you gate features per tier so one binary unlocks different capabilities per plan. Trials are self-service and abuse-resistant. And there is a hosted customer portal so seat moves and re-downloads never land in your inbox.

The .NET SDK does the client half honestly: Validate() verifies everything offline and never throws, ActivateAsync() handles online seats with an offline grace window, and the whole thing fails closed to the free edition by design. It multi-targets from .NET Framework 4.8 to current .NET, with sibling SDKs for Node, Python, and Java sharing one tenant and one public key.

Keyright is a fully hosted SaaS today, with a self-host option on the roadmap for teams that need the issuing service inside their own infrastructure. There is a genuinely free plan — up to 50 active licenses on one product, no card — so you can ship real licensing before you pay anything.

The bottom line

The build-vs-buy decision isn’t about whether you can write an RSA verify — of course you can. It’s about whether you want to own a stateful, security-sensitive backend (key management, seat counting, revocation, trials, a portal) that no customer will ever thank you for. If your needs are trivial and fixed, build the weekend version and move on. Anything more, and a service pays for itself the first time you dodge a key-rotation incident or a support queue full of seat-move requests.

If you want to try the buy path, start with the Keyright getting-started guide or see the plans — the free tier is enough to wire up real licensing end to end before you decide.