DEV Community: PermitCore

Perpetual License vs Subscription License: Which Should You Sell?

PermitCore — Sun, 01 Nov 2026 09:27:06 +0000

Originally published on the PermitCore blog.

Perpetual and subscription aren't really about the license technology at all. A license key doesn't care whether it's "supposed to" last forever. The real difference is a business model decision: does the customer own access forever after one payment, or do they keep paying to keep access? Most licensing platforms, including ours, can issue either from the exact same product.

How purchase type determines access

For a one-time purchase in PermitCore Store, LicenseExpiryDays sets the number of days of access; leaving it blank creates a perpetual key. Monthly and annual purchases follow Stripe's paid billing period instead: each paid invoice extends the same key. Failed renewals use the configured payment grace window, 14 days by default, and access expires when it ends.

A product can offer one-time, monthly, and annual options side by side; the selected purchase type determines which expiry rule applies. Activations, node locking, and feature flags remain independent controls.

Perpetual: what you're actually trading

A perpetual license (one payment, access forever) is simple to explain to a customer and creates no ongoing billing relationship to maintain: no dunning emails, no cancellation flow, no "why was I charged again" support tickets.

The tradeoff is revenue shape. Each sale is a one-time event, so growth depends entirely on new customers or paid upgrades, not a compounding base of renewals.

It also creates a real, ongoing support obligation most vendors underestimate. A customer who paid once five years ago may still expect their software to run, even as the OS and platform change underneath them. Perpetual access does not itself promise endless feature upgrades or commercial support. Applicable security-support duties need separate assessment; they are not erased by an expired upgrade contract. Our CRA support and licensing guide goes deeper. In short: state the purchased execution rights, the upgrade policy and the security-support period separately.

Subscription: what you're actually trading

A subscription (recurring charge, access requires staying current) creates a predictable, compounding revenue base and a natural way to fund ongoing development. The customer relationship doesn't end at the sale.

The tradeoff is operational surface:

Failed payments need handling (grace window, then expiry).
Cancellations need a clean flow.
Every renewal is a moment a customer can decide to leave, so churn becomes a metric you actively manage.

Selling both isn't unusual

A common pattern: subscription as the default (lower upfront price, steady revenue) with a perpetual option at a higher price point for customers who specifically want to avoid recurring billing. Enterprise procurement teams in particular often prefer a one-time purchase over an operating subscription for budgeting reasons that have nothing to do with your product.

Since both are just a price plus an expiry setting on the same product, offering both isn't extra engineering work, just a second price point.

What doesn't change either way

Node-locking, floating seats, feature gating, and offline support are all independent of whether the license is perpetual or subscription. The perpetual-vs-subscription decision is purely about the business model; how the license actually behaves on a customer's machine is a separate, orthogonal choice.

Which model are you selling right now, and what made you pick it? I'd love to hear how other indie devs decided. 🙂

How to Implement Feature-Based Licensing

PermitCore — Fri, 30 Oct 2026 09:33:17 +0000

Originally published on the PermitCore blog.

"Is this license valid?" is often the wrong question. The more useful one is usually "what does this specific license unlock?" A Pro customer and a Team customer might both hold a genuinely valid key, but your app needs to know which of them gets the export button, SSO, or the API integration. That's feature-based licensing, and it's a field on the license key itself, not a separate system.

Where features live

Every LicenseKey has a FeaturesJson field: a plain JSON array of feature-flag strings, e.g. ["export","api","sso"]. You set this when you create a key (or define it once on a License Template so every key generated from that template inherits the same list), and it's returned in full on every validate()/activate() call, no separate endpoint required.

Reading it in your app

The response's features field is a plain string array. PermitCore's .NET SDK adds one convenience method on top of it:

/// Returns true if this feature flag is in the license's feature list.
public bool HasFeature(string feature) =>
    Features?.Contains(feature, StringComparer.OrdinalIgnoreCase) ?? false;

In your own code, that's a one-line gate:

var result = await client.ValidateAsync(licenseKey);

if (result.HasFeature("export"))
    exportButton.Visible = true;

if (result.HasFeature("sso"))
    EnableSsoLogin();

The check is case-insensitive on purpose: a casing difference between how a feature was set on the key and how you check it in code is exactly the kind of bug that only shows up for one customer, weeks later.

Two ways to assign features

Per-key. Set FeaturesJson directly when creating or editing an individual license. Useful for a one-off custom deal or an enterprise customer with a negotiated feature set that doesn't match any of your standard tiers.

Via a License Template. Define a template once (e.g. "Pro Template" with ["export","api"], "Team Template" with ["export","api","sso","seats"]) and every key generated from it, whether created manually, through the Store, or via the Stripe checkout flow, inherits that feature list automatically. This is the right approach if you're selling more than one tier: define the tiers as templates once, and every future key just picks one.

Where this fits versus other licensing controls

Feature flags answer "what can this customer do," which is a different question from what node-locked vs. floating answers ("how many devices or seats can use it") or what an expiry date answers ("for how long"). Most real products combine all three: a Pro-tier key might be node-locked to 2 devices, expire in 12 months, and unlock a specific feature set, all on the same license.

How do you split features between tiers in your own product: flags on the license, or separate builds? 🙂

How to Prevent License Key Sharing (Three Layers That Work Together)

PermitCore — Wed, 28 Oct 2026 09:31:54 +0000

Originally published on the PermitCore blog.

A license key on its own is just a string. Nothing stops someone from pasting a valid one into a forum thread or a Discord server unless the system that checks the key actually does something about it. Here are three complementary techniques we use in PermitCore. Each one covers a different sharing pattern, and together they make casual key-sharing genuinely inconvenient.

1. Node-locking: tie a key to a device

Every license has a Max Activations limit: how many distinct devices it can be active on at once. With node-locking on, the first activate() call binds the key to a hardware fingerprint (a hash derived from stable machine identifiers, nothing personally identifying). Reactivating on the same device doesn't use a new seat, but a genuinely different machine does, and once the limit is reached the next machine is rejected.

That's the first line of defense: sharing a key with a friend costs one of your own seats the moment they use it, and once the limit is hit, both of you find out immediately. The device activation guide covers how the fingerprinting works.

2. Floating licenses: shared seats, not shared copies

For team products where node-locking doesn't fit, for example a license that should float to whoever on the team is using the app right now, floating (concurrent) licenses work better. A fixed number of sessions are checked out and released as people start and stop the app. When every seat is taken, the next activation waits until someone checks theirs back in.

Simultaneous use stays bounded by what was paid for; it's just counted per concurrent session instead of per permanent device.

3. Abuse detection: the pattern seat limits can't see

A key with a generous seat count (say a 50-seat team license) can still be posted publicly and used by far more than 50 people over time, as long as no more than 50 are active at once. Every individual request looks legitimate.

So we watch for that pattern directly: per license key, how many distinct caller IPs hit validate() / activate() within a rolling one-hour window.

private const int RequestSuspiciousThreshold   = 200;  // requests/hour
private const int RequestBlockThreshold        = 2000; // requests/hour
private const int IpFanoutSuspiciousMultiplier = 5;    // × MaxActivations
private const int IpFanoutSuspiciousFloor      = 20;   // distinct IPs/hour, minimum
private const int IpFanoutBlockMultiplier      = 20;   // × MaxActivations
private const int IpFanoutBlockFloor           = 100;  // distinct IPs/hour, minimum

The threshold scales with the license's own seat count. A 1-seat license reaching 20 distinct IPs in an hour is already abnormal, while a 500-seat license needs proportionally more before it's flagged. There are two tiers:

Suspicious: the request is still served, so a real customer is never blocked over a false positive, but an audit entry is written and a license.abuse_suspected webhook fires (at most once per key per hour) so you can decide what to do.
Block: well past the suspicious threshold, the request is rejected outright before any database work, which protects your infrastructure from a key that's clearly being hammered from everywhere.

Why layering matters

Node-locking and floating limits bound how much simultaneous use one key can support. Abuse detection catches the slower leak, where a key spreads more widely than its seat count alone would reveal. Combined with revocation, you can shut a leaked key down the moment the webhook tells you about it, without touching paying customers.

How do you handle leaked keys in your own products today: hard limits, monitoring, or just revoking when someone reports it? 🙂

Node-Locked vs. Floating Licenses: Which One Do You Need?

PermitCore — Mon, 26 Oct 2026 09:39:52 +0000

Originally published on the PermitCore blog.

Both options sit right next to each other on a typical Create License form, and it's not always obvious which one fits your product. The short version: node-locked ties a key to specific machines; floating ties a key to a pool of concurrent seats that any machine can borrow from. Here's when each one actually makes sense.

Node-Locked: One Key, Specific Machines

A node-locked license binds to a device's hardware fingerprint the first time it's activated, and stays bound until it's explicitly deactivated. MaxActivations is a hard ceiling on how many distinct devices can ever hold that key at once.

This is the right default for most desktop software: a customer buys one seat, installs it on their one work laptop, and that's that. It's simple to reason about, simple to support, and matches how most customers already think about "a license."

Floating: A Shared Pool of Seats

A floating license doesn't permanently tie itself to any machine. Instead, your app checks out a seat when it starts, and checks in (releases it) when it closes, or after a heartbeat timeout if it crashes without checking in cleanly. MaxActivations here means "how many machines can be actively using the software right now," not "how many machines have ever run it."

A 10-seat floating license lets any number of employees install the software, but only 10 can have it open at the same time.

This is the right fit for office software used by a team that's never all logged in simultaneously: CAD tools, analytics dashboards, anything where you'd rather sell "10 concurrent users" than "10 named installs."

// On app start
var session = await client.CheckoutFloatingSeatAsync(key);
if (!session.IsValid)
{
    // result.ErrorCode == "SeatsExhausted" means every seat is in use right now
    ShowNoSeatsAvailable();
    return;
}

// Periodically, while the app is running
await client.HeartbeatAsync(session.SessionId);

// On clean app shutdown
await client.CheckinFloatingSeatAsync(session.SessionId);

Side by Side

	Node-Locked	Floating
Ties to	a specific device	a seat pool, any device
"Seats" means	total installs ever	concurrent active users
Needs	activate/deactivate	checkout/heartbeat/checkin
Best for	1 user, 1 machine	shared office tools

What Happens If a Floating Session Never Checks In?

If a customer's machine crashes, loses power, or their app process is killed rather than closed cleanly, the seat isn't lost forever: a missed heartbeat past the configured timeout automatically frees the seat back into the pool for the next machine that needs it.

What's Next

Both models assume you're selling directly through your own app. The other distribution path is a built-in license store, for teams who want a real checkout page and automatic key delivery without building any of that themselves: Setting Up a License Store.

Which model do you use for your own desktop app, and did you ever have to switch? 🙂

How to Build a License Key System

PermitCore — Fri, 23 Oct 2026 08:28:35 +0000

Whether you build one yourself or use a service, every license key system is answering the same three questions: what does a key look like, how do you check one without leaking what a valid one looks like, and how do you stop a valid key from working everywhere at once. Here's the real architecture, independent of any particular vendor.

Designing the key format

A license key is a string a human might need to type, read over the phone, or paste from an email — that constrains the design more than it first seems. A sensible format groups characters for readability (PERMIT-XXXX-XXXX-XXXX-XXXX rather than one long block), and a good charset avoids characters that are easy to confuse when hand-typed or read aloud — no 0/O, no 1/I/l. A real example: ABCDEFGHJKLMNPQRSTUVWXYZ23456789 — deliberately missing the ambiguous characters, 32 symbols so each character carries 5 bits of entropy, and a 20-character key (the four XXXX groups) gives 100 bits — comfortably beyond brute-force range.

Never store the plaintext key server-side

This is the part naive implementations get wrong most often: storing the key as plaintext (or as a reversible encryption of it) means a stolen database dump hands an attacker every valid key directly. The correct approach is a one-way transform — hash the key, and look it up by hash, not by the key itself. A plain hash isn't quite enough either: a fast hash function (SHA-256 alone) lets an attacker with a stolen dump brute-force short/predictable keys offline at billions of guesses per second. The fix is a keyed hash — HMAC with a secret that lives only on your server, never in the database — so even a full database theft is useless without also stealing the separate secret.

The lookup path

// Customer sends the plaintext key in a POST body (never a URL — keeps it out of
// access logs, browser history, and CDN caches)
var hash = HMAC_SHA256(serverSecret, SHA256(plaintextKey));

// Look up by the keyed hash, never by the plaintext key itself
var license = db.LicenseKeys.FirstOrDefault(l => l.KeyHash == hash);

This gives you the property that matters most: your server can validate a key it has never seen the plaintext form of stored anywhere, and a database breach alone — without the separate HMAC secret — is not enough to forge or verify keys.

Activation limits need a real lock, not just a count check

A naive "read the count, check it's under the limit, then increment" has a race window: two devices activating a nearly-full license within milliseconds of each other can both read the same under-limit count and both succeed, overselling a seat. The fix is an atomic conditional update (UPDATE ... SET count = count + 1 WHERE count < max, checking the database's own row affected count) or a database-level lock scoped to that one license — tested against genuinely concurrent requests, not just sequential ones, since the race only shows up under real concurrency.

What tends to get skipped, and shouldn't

A system that only handles the happy path is missing: per-key failed-lookup rate limiting (so a script can't enumerate keys by brute force), abuse detection for a valid key shared across too many distinct callers (a different problem than a rate limit catches — see how PermitCore detects this), and an offline story if your app needs to keep working without a network call (see device fingerprinting and offline validation). None of these are exotic — they're just easy to underestimate until a real customer hits the gap.

If building all of this yourself sounds like more than you want to maintain long-term, that's the actual tradeoff a licensing API like PermitCore is solving — see our honest build vs. buy breakdown for the fuller picture either way.

Originally published on the PermitCore blog. How do you handle license keys in your own apps? I'd love to hear what's worked for you.

PermitCore Store 2.0: a branded software storefront built into licensing

PermitCore — Mon, 12 Oct 2026 15:50:23 +0000

A licensing API solves key creation and validation. It does not automatically give a software vendor a polished way to present products, run promotions, take payment, deliver licenses, and support customers after checkout.

That is why we rebuilt the PermitCore Store.

Store 2.0 is a responsive, vendor-branded software storefront connected directly to the same products, prices, entitlements, orders, subscriptions, and licenses managed in PermitCore.

Merchandising without building another application

Vendors can now create a storefront with:

hero campaigns and featured releases
curated product collections
category and workflow tiles
horizontal product shelves
custom colors, backgrounds, images, spacing, and labels
search and responsive desktop/mobile navigation

Every section can be configured from the Shop Designer instead of being hard-coded into a separate storefront project.

Trials, bundles, and scheduled discounts

Store 2.0 supports one-time and subscription products, free trials, bundles, scheduled promotions, percentage or fixed-value discounts, and campaign labels.

For discounted offers, vendors can also show the lowest applied price from the previous 30 days. This gives EU-facing stores the information needed for transparent discount presentation while keeping the display configurable for stores operating elsewhere.

Checkout and licensing stay connected

A buyer can discover a product, add it to the cart, pay through the vendor's connected Stripe account, and receive the correct license automatically.

The complete workflow is:

Create a product and define its license rules.
Implement validation through the REST API or one of eight official SDKs.
Merchandise the product in a branded Store 2.0 storefront.
Accept payment through the vendor's own Stripe account.
Generate and deliver the correct license automatically.

PermitCore takes 0% commission on software sales. The vendor keeps the Stripe relationship while PermitCore connects checkout to customers, orders, invoices, subscriptions, entitlements, and license delivery.

Built for desktop and mobile

The storefront, product pages, cart, checkout flow, and customer account are responsive. Storefront content is cached for fast delivery, while checkout, account, and license operations remain protected by the platform's authorization, rate-limiting, and tenant-isolation controls.

Try the presentation store

We turned Nexova into a complete demo storefront so the entire flow can be explored with realistic products, imagery, bundles, trials, and discounts.

How are you currently connecting product discovery, checkout, and license delivery?

Offline licensing for a Python desktop app without calling home on every launch

PermitCore — Tue, 29 Sep 2026 18:48:19 +0000

Some desktop applications cannot depend on an internet connection every time they start. The useful security model in that case is not to hide a shared secret inside the Python package. It is to verify a signed license token locally with a public key.

The server keeps the private signing key. The application receives only the public verification key, so it can verify authenticity without gaining the ability to create new valid licenses.

I wrote a practical PermitCore guide for this flow:

pip install permitcore[offline]

On the first run, verify the signed token and bind it to the device:

from permitcore import PermitCoreClient

activated = PermitCoreClient.activate_offline(
    token, public_key_base64, device_id
)
if not activated.is_valid:
    raise RuntimeError(activated.message)

Later launches can validate the stored activation locally, with zero network calls:

result = PermitCoreClient.validate_offline(device_id)

A good test is to change one character in the activation token and confirm that signature verification fails. I would also test expired tokens, the wrong device, a missing local cache, and the customer workflow for moving to replacement hardware.

For device identity, avoid treating a raw MAC address as a permanent machine ID. It can change, it is privacy-sensitive, and virtual/network adapters make it unreliable. Use a stable identifier appropriate for the platform and define an explicit transfer policy.

The same product can then be published in PermitCore's built-in Store. The Store uses your Stripe account, takes 0% PermitCore commission, and delivers the license after checkout. That completes the full create → implement → sell path even for an offline-ready desktop edition.

Full walkthrough

How to add offline licensing to a Python desktop app

PermitCore

PermitCore is an early-stage developer-first startup, so feedback on the offline workflow and the guide is very welcome. 🙂🚀

Where license validation belongs in an Electron app

PermitCore — Tue, 29 Sep 2026 18:47:25 +0000

If an Electron app checks its license in renderer code, a customer can inspect the same code that makes the allow-or-block decision. That does not make the app impossible to protect, but it puts an important decision in the easiest process to inspect and modify.

For a paid Electron app, I prefer this boundary:

validate in the main process;
keep contextIsolation enabled;
expose only the minimum license status through a narrow preload/IPC API;
scope every validation request to the product ID;
test the packaged build, not only development mode.

The core integration can remain straightforward:

import { app } from 'electron';
import { PermitCoreClient } from '@permitcore/permitcore';

const client = new PermitCoreClient('https://api.permitcore.dev');
const result = await client.validate(
  licenseKey,
  app.getVersion(),
  productId
);

if (!result.isValid) app.quit();

I wrote a complete walkthrough covering installation, activation, product-scoped validation, offline grace, revoked-key testing, and the main-process/renderer boundary.

It also covers the step that licensing tutorials often omit: selling the application. PermitCore includes a branded Store, so the same product can have a checkout that uses your Stripe account, creates the license after payment, and delivers it to the customer. PermitCore takes 0% sales commission.

The intended workflow is create → implement → sell, without maintaining a separate storefront and webhook bridge just to issue keys.

Full walkthrough

How to license and sell an Electron app

PermitCore

If you ship Electron applications, I would be interested to hear how you currently separate licensing logic from renderer code and how you handle offline customers. 🙂🚀

A practical license-key flow for a .NET desktop app, including the sale

PermitCore — Tue, 29 Sep 2026 18:41:28 +0000

Adding a license check to a .NET desktop app is easy to underestimate. The first API call is usually the simple part. Production behavior is where the real work begins: product scoping, device activation, offline grace, license transfer, failed payments, and getting the key into the customer's hands.

I put together a .NET tutorial that treats licensing as a complete product flow rather than one IsValid check.

Install the client:

dotnet add package PermitCore.Client

Then validate the key against the application version and the exact product:

using PermitCore;
using System.Reflection;

var client = new PermitCoreClient("https://api.permitcore.dev");
var version = Assembly.GetEntryAssembly()?.GetName().Version?.ToString() ?? "1.0.0";

var result = await client.ValidateAsync(
    licenseKey,
    version: version,
    expectedProductId: productId);

if (!result.IsValid)
    return ShowActivationWindow(result.Message);

Before shipping, I would test at least these cases in the packaged application:

the correct license and product;
a valid license for a different product;
an expired or revoked license;
a device over its activation limit;
a temporary network failure while offline grace is available;
releasing an activation and moving the license to another computer.

The tutorial also finishes the commercial side. You can create a matching Store product, use one-time or recurring Stripe pricing, and have checkout generate and email the license. PermitCore uses the vendor's Stripe account and takes 0% PermitCore commission.

That is the distinction I wanted when building it: developers can create the license, implement it, and sell the software without maintaining a separate checkout-to-license webhook system.

Full walkthrough

How to add license keys to a .NET application

PermitCore

This is still an early-stage startup and I would especially appreciate feedback from people who ship WPF, WinUI, Avalonia, MAUI, or other desktop applications. 🙂🚀

How I added licensing and checkout to a Unity project without building two more systems

PermitCore — Tue, 29 Sep 2026 18:29:54 +0000

When I started working on software licensing, the part that bothered me was not only validating a key. A paid Unity game or asset needs the whole path: a product, a license policy, SDK integration, payment, and finally a way to deliver the right key to the customer.

Most licensing services stop after validation. You still need to connect a separate storefront, handle payment webhooks, generate the license, and send it to the buyer. That can become a second product to maintain before the actual game or tool has made its first sale.

I wrote a practical Unity guide showing the complete flow with PermitCore:

Create a product and choose device, version, and offline rules.
Install the Unity SDK through Package Manager.
Validate the license against the expected product ID.
Test revoked, expired, wrong-product, and activation-limit responses.
Publish the same product in a branded Store, connect your Stripe account, and let checkout issue and deliver the license automatically.

The integration itself stays small:

using PermitCore;
using UnityEngine;

var client = new PermitCoreClient("https://api.permitcore.dev");
var result = await client.ValidateAsync(
    licenseKey,
    Application.version,
    productId);

if (!result.IsValid)
    ShowLicenseScreen(result.Message);

The important detail is productId. A structurally valid key should not unlock the wrong game, asset, edition, or DLC. I also recommend testing a revoked key in the actual release build rather than stopping after the happy path works in the editor.

PermitCore's Store uses your own Stripe account and takes 0% PermitCore sales commission. The goal is to keep licensing and selling in one workflow: create → implement → sell.

Full walkthrough

How to sell licenses for a Unity game or asset

PermitCore

I am building this as a small developer-first startup, so feedback from Unity developers is very welcome. If something in the guide is unclear, you can reach me through Contact Us on the site. 🙂🚀

Why a licensing API is only half of the product

PermitCore — Mon, 21 Sep 2026 18:13:51 +0000

When we first looked at software licensing, the problem seemed straightforward: create a license key, validate it inside the application, and manage activations.

Then we reached the part where somebody actually has to buy the license.

That turns licensing into a much larger project. You need a product page, pricing, checkout, payment verification, customers, orders, subscriptions, license fulfillment, delivery, and somewhere for the customer to find what they purchased. The license API may be ready, but the commercial workflow is still another product to build and maintain.

That is the gap we are trying to close with PermitCore.

Create → implement → sell

PermitCore connects the full workflow:

Create a product and define its license rules.
Add validation with the REST API or one of eight official SDKs: .NET, Node.js, Python, Java, C++, PHP, Go, and Unity.
Publish the product in a customer-facing Store under your own brand.
Accept payment through your connected Stripe account.
Generate and deliver the working license automatically after checkout.

Products, prices, orders, customers, subscriptions, entitlements, and licenses stay connected instead of being split across a licensing dashboard, a custom checkout service, and several webhook handlers.

Why we made the Store part of licensing

Many licensing platforms treat commerce as an integration boundary.

For example, Keygen documents a Stripe flow where Stripe communicates with the licensing service through webhooks. LicenseSpring connects license fulfillment to services such as Stripe, FastSpring, and Shopify. Those are valid approaches, especially if a team already has a mature commerce stack.

But for an indie developer or a small software team, the missing checkout and fulfillment layer can become a second application. It has its own security work, failure states, support burden, and maintenance cost.

PermitCore takes a different approach: the Store is part of the licensing product. A vendor can go from defining a license to publishing the product for sale without building a separate commerce backend.

Your Stripe account, 0% PermitCore commission

Payments go directly through the vendor's connected Stripe account. PermitCore does not take a percentage of software sales.

That means the Store removes integration work without becoming a marketplace that sits between the vendor and the customer. Stripe still handles the payment relationship, while PermitCore connects a successful checkout to the correct order, entitlement, and license delivery.

When a separate commerce platform still makes sense

The built-in Store will not be the right answer for every business. If you already run a large Shopify, WooCommerce, or custom commerce operation, keeping that system and connecting fulfillment may make more sense.

Our goal is to give developers a complete default path when they do not want to build that entire layer themselves.

We are still a startup and continuing to produce documentation and videos, so our social channels are smaller than the product today. If you need anything while evaluating PermitCore, use the Contact Us page and we will help directly.

Website: https://permitcore.dev
Store overview: https://permitcore.dev/solutions/sell-license-keys
Product video: https://www.youtube.com/watch?v=148yf66x9IM
YouTube: https://www.youtube.com/@PermitCore
X: https://x.com/permitcore

How are you handling this in your own products: a custom checkout, an external commerce platform, or one connected licensing and sales workflow?

🙂🚀

Why we built PermitCore: software licensing shouldn’t become a second product

PermitCore — Thu, 10 Sep 2026 17:41:53 +0000

Hey DEV community,

I want to introduce PermitCore, a software licensing platform we built for independent developers and software teams.

The idea came from a problem we kept running into ourselves. Whenever we built software that needed licensing, we also had to build and maintain a separate system for license keys, device activations, expiration rules and customer access.

That infrastructure quickly started feeling like another product we had to maintain.

So we built PermitCore to handle it.

PermitCore currently supports:

License key creation and management
Device activation limits
Expiration and revocation
Offline license validation
Floating licenses and concurrent seats
Entitlements and feature access
Customer and reseller portals
Payments and webhooks
Zero-knowledge encryption
A REST API and SDKs for .NET, Node.js, Python, Java, C++, PHP, Go and Unity

There is a free plan that stays free, because we want indie developers to have something useful while getting their first products off the ground. We also offer a three-month free trial for anyone who wants to test the wider feature set without commitment.

PermitCore is still an early startup, and we’re continuing to improve both the product and our documentation. Our social channels are also fairly new, so I hope you won’t mind that there isn’t a huge amount of content there yet.

I’d really appreciate feedback from developers who have built licensing systems before or are currently deciding how to protect and sell their software.

Website: https://permitcore.dev

Documentation: https://permitcore.dev/docs/getting-started

YouTube: https://www.youtube.com/@PermitCore

X: https://x.com/permitcore

If you have any questions or need help integrating it, feel free to reach us through the Contact Us page on the website.

Thanks for taking a look 🙂 👋