This is the checklist I'd give anyone selling their first piece of software. It's in the order you'll need it, and every step works whatever you sell and wherever you sell it.

I build SunLicense, a licensing service for people who sell plugins, scripts, bots and apps, and I use it as the worked example in the protection, refund and support steps.

1. Make sure it's ready to sell

Free users forgive rough edges. Paying users email you about them. Before you list it:

• Install it on a clean machine or server, from the file you'll sell, following only your own README. Fix everything that trips you up.
• Give it a version number (1.0.0) and keep a short changelog from now on.
• Write down what it needs: game or server versions, Java, Node.js or Python version, operating systems.
• Decide what's included: is the source included? Can buyers modify it? Can they use it on more than one server? That becomes your license terms.

2. Pick where to sell it

Where your buyers already shop matters more than anything else. A Minecraft server owner looks on Minecraft marketplaces; a developer buying a desktop tool is happy with a checkout link on your own site.

Before you pick, read each store's rules for your kind of product (many have rules on DRM and licensing) and check who handles sales tax and VAT. Marketplaces bring buyers; your own site keeps more control.

3. Set a price

There's no formula, but there is a method:

1. Look at similar products in the same store, and note what they charge and what they include.
2. Price for the problem you solve, not the hours you spent. A plugin that saves a server owner a weekend is worth more than one that adds a nice hat.
3. Choose one-time or subscription. One-time is the norm for plugins and scripts; subscriptions fit products with ongoing costs or frequent updates (a hosted service, a bot with an API behind it).
4. Keep a free version or a trial if you can. It's the best advert you have.
5. Don't start too low. Raising a price later is harder than running a launch discount now.

4. Write a listing that answers questions before they're asked

A good listing has: one sentence on what it does, a short video or 3-5 screenshots, a feature list, requirements (from step 1), how installation works, how to get support, your refund policy, and your terms (from step 1). Every question your listing answers is a support message you don't get.

5. Protect it: one key per buyer, a check on start-up

The first leak usually isn't a cracker. It's one buyer sharing their download. What stops most of it: every buyer gets their own license key, your product checks it when it starts, and each key only runs on a few machines. Here's how that looks with SunLicense (free for 3 products and 100 licenses), step by step.

5a. Create a product and a policy. Sign up (Google, GitHub, Discord or email), create a product, then a policy: what one purchase allows. Set Max machines to fit what you sell: 1-3 servers for a plugin or script, 2-3 machines for a desktop app. A shared key runs out of slots; buyers who move hosts can free one.

5b. Connect your store. On the Integrations page, pick where you sell. Each sale then creates a license for that buyer, without you touching it:

Payhip, Ko-fi, itch.io, SpigotMC and others are on the same page.

5c. Add the check to your product. Use the SDK for your language (Java, JavaScript, Python, .NET, PHP or Lua), or let your coding agent do it: Products → your product → Setup → Copy prompt, paste it into Claude Code, Cursor or Codex, and it adds the check and tests it with a test license. Whichever way, follow the one rule that keeps buyers happy: only stop on a clear "no" (suspended, revoked, expired, too many machines). If the license server can't be reached, keep running.

5d. Obfuscate the release build. Developers → Obfuscation takes a Java jar (ProGuard, Skidfuscator, or both with Maximum), JavaScript, Python or a zipped FiveM resource, 3 free runs a month. It makes the check and your code harder to find and patch. It slows people down; it doesn't stop a determined cracker.

6. Decide how refunds work, and let them revoke the key

Write your refund policy down (for example: within 7 days if it doesn't work on your server and support couldn't fix it), put it in the listing, and stick to it.

Then make sure a refund also takes the license away, or every refund is a free copy. With the store connected in 5b, Tebex, Voxel Shop, Stripe, Gumroad and Lemon Squeezy refunds revoke the key automatically: the buyer's copy stops at its next check, and everyone else is untouched. BuiltByBit's placeholder carries no refund information, so there you revoke the key yourself from the license page when you refund.

The Licenses tab shows every buyer, their policy and status. Suspend a key while you sort out a dispute, reinstate it when it's resolved, or revoke it for good.

7. Set up support before the first sale

• One place for support: a Discord server is the norm for plugins, scripts and bots; email works for apps.
• A buyer role in that Discord. The SunLicense Discord bot (on every plan) posts a claim panel: buyers enter their key and purchase email, get your "Customer" role, and lose it if the license is revoked or expires.
• A short FAQ with the five questions you expect (installation, where the key goes, moving to a new server, updates, refunds). Add to it every time you answer something twice.
• Say how fast you reply ("within a day"), and keep to it.

8. Plan your updates

• Ship small updates often, with the changelog in each one. Buyers judge a product by how alive it looks.
• Don't break existing setups. Keep config files compatible and say clearly when they aren't.
• Keep old license keys working across versions, so updating never means asking for a new key.

Launch-day checklist

The last item, a test purchase of your own product, catches more problems than everything else on the list.

Get started

Everything in steps 5 to 7 is on SunLicense's free plan: connect your store, add the check, obfuscate the release, and post the claim panel in your Discord. It covers 3 products and 100 licenses, with store integrations, SDKs, obfuscation and the Discord bot, no credit card and no cut of your sales. See how it works, then work down the launch-day checklist.

You can't make piracy impossible, and trying to usually hurts paying customers more than pirates. What you can do is make sharing inconvenient, make leaks traceable, and make paying the easy option. This is the plan I'd follow, in order. Each step is worth doing on its own, so stop wherever the effort stops paying off.

Step 0: Decide what you're actually fighting

Most losses sit in the first two rows, and those are the cheapest to fix.

Step 1: Give every buyer their own key, automatically

A single shared password or license file can't tell anyone apart. Give each purchase its own key, so you can see who's using what and switch off exactly one person.

Don't do it by hand. Connect your store so keys are created at checkout. On BuiltByBit, an External license key placeholder writes the buyer's key into the jar they download. Voxel Shop and SpigotMC have their own placeholders, and Tebex, Stripe, Gumroad, Lemon Squeezy and others can create a key through a webhook. Wire refunds in too, so a refunded purchase loses its key.

Step 2: Limit where a key can run

A key that works everywhere is a key that gets shared. Set a limit that fits the product:

• Plugins: servers per key (1-3 is typical).
• Desktop apps: machines per key (2-3 covers a laptop and a desktop).
• Bots or web tools: an IP address limit.

When the limit is reached, a new machine is refused with a clear message, and the buyer can free a slot themselves. Be generous: a support ticket costs you more than one extra machine.

Step 3: Check at startup, and never take a customer down

Check the license when the app starts, then again every few hours. No need to phone home every minute. Above all, only stop on a clear "no" (revoked, suspended, expired, too many machines). If your license server can't be reached, keep running. BuiltByBit's DRM guidance says the same, and plugins that disable themselves when a server is down risk being removed. For a Minecraft plugin, I walk through this check line by line in How to add license keys to a Minecraft plugin in 10 minutes.

For customers without internet, ship a signed offline license: a file signed with a private key (Ed25519, for example) that your app verifies with the public key, and that expires on a date you set.

Step 4: Make the check hard to delete

A license check is one if statement. Anyone with a decompiler, or an AI editor, can delete it. Two things make that pointless:

• Core unlock. Encrypt a small, essential piece of your code (a core class, default rules, a lookup table) and only decrypt it after a valid license check. Delete the check, and that piece is simply missing.
• Tamper reports. Hash your own classes and report a modified copy with the next license check, so you know which license runs a patched build.

Step 5: Obfuscate your release builds

Rename classes and methods, encrypt strings and scramble control flow, so your check and your core are hard to find and patch. ProGuard gives a safe rename; ProGuard followed by Skidfuscator adds control flow and string encryption. Only obfuscate the build you sell, test it before upload, and keep the mapping file so you can read customers' stack traces. I wrote a step-by-step guide: How to obfuscate a Minecraft plugin.

Step 6: Watermark every download

Put something in each buyer's copy that names them: their license key in the jar, an ID in the manifest, a mark in the archive. When the jar shows up on a leak site, you know whose it was without guessing. It also deters sharing: people think twice when their copy carries their name.

Step 7: Watch for sharing

You won't spot a shared key by reading logs. Get alerts for the patterns that matter: one key on many machines at once, a key checking in from two countries an hour apart, a machine trying random keys, a revoked key still in use, a key pasted in your Discord. Then act on the real ones (a customer who travels isn't a pirate).

Step 8: Respond fast when something leaks

1. Find the buyer from the watermark or the key in the leaked file.
2. Revoke that key. Copies stop at their next check; everyone else is untouched.
3. Send a takedown notice (DMCA) to the site hosting it. Most marketplaces also have a DMCA form.
4. Revoke refunded and charged-back purchases too, or they keep a free copy.

Step 9: Make paying easier than pirating

The best anti-piracy feature is a product that's easy to buy. A fair price, a trial, fast updates, real support and a Discord. A pirate gets an old jar and no help. A customer gets the update that fixes their bug today.

The whole plan on one page

How to put it together

You can build each layer yourself: a small key server, a signing key, an obfuscation step in your build, and a dashboard to revoke from. Or use a service. I build SunLicense, which covers the list:

It's free for 3 products and 100 licenses, with no credit card and no cut of your sales. See what SunLicense covers, then work through the list, starting with step 1.

This guide walks through selling a self-hosted bot with a license key per buyer: issuing keys when people pay, checking them in discord.js or discord.py, keeping the bot up when the licensing server is down, and giving buyers a role in your support server that follows their license.

I build SunLicense, the licensing service used in the examples. The pattern works with any licensing API.

First, do you need this? If you host the bot yourself and sell access per server, you don't need license keys: you already control who it runs for. Keys are for bots that buyers download and run on their own machine or VPS.

How it fits together

1. A buyer pays in your store. The store tells the licensing service, which issues a key.
2. The buyer puts the key in the bot's .env next to their Discord token.
3. The bot checks the key when it starts and every few hours. Valid: it logs in. A clear "no": it stops.
4. A refund revokes the key (a chargeback suspends it); the next check stops the bot.

Step 1: create a product and a policy

In SunLicense, create a product for the bot and a policy for what one purchase allows: for example a perpetual license with a limit of 1 or 2 machines. The machine limit is what turns a shared key into a useless one: once its slots are taken, the next server is refused, and buyers can free a slot themselves when they move hosts.

You also create an API key (slk_...) for the bot. It can only validate licenses, so it's the one that ships inside the bot. Never ship a personal access token.

Step 2: issue a key per buyer from your store

Connect your store on the Integrations page so every sale creates a license without you touching it:

Payhip, Ko-fi, itch.io, Tebex and others work the same way. Selling to one customer by hand? Issue a license from the dashboard or from Discord with /license issue.

Step 3: check the license when the bot starts

The rule that keeps both you and your buyers happy: check on startup, re-check every few hours, stop only on a clear "no", and keep running when the licensing server can't be reached. An outage on your licensing provider's side should never take your customers' bots offline.

The SDK sends POST /api/v2/license/validate. HTTP 200 means valid, 400 means rejected (the body's code says why: SUSPENDED, REVOKED, EXPIRED, a full machine limit). Anything else, or a network error, means "couldn't check".

discord.js

// npm install sunlicense discord.js
import os from "node:os";
import { Client, GatewayIntentBits } from "discord.js";
import { SunLicense } from "sunlicense";

const sunlicense = new SunLicense({ baseUrl: "https://api.sunlicense.com", token: process.env.SUNLICENSE_API_KEY });
const machineId = os.hostname(); // or an id you generate once and store

async function checkLicense() {
  try {
    const r = await sunlicense.validate(process.env.LICENSE_KEY, { host: machineId });
    if (r.valid) return { ok: true };
    if (r.status === 400) return { ok: false, code: r.data?.code };   // a clear "no"
  } catch {}
  return { ok: true, unreachable: true };                            // fail open
}

const first = await checkLicense();
if (!first.ok) {
  console.error(`License rejected (${first.code}). The bot will not start.`);
  process.exit(1);
}

const client = new Client({ intents: [GatewayIntentBits.Guilds] });

setInterval(async () => {
  const s = await checkLicense();
  if (!s.ok) {
    console.error(`License rejected (${s.code}). Stopping.`);
    await client.destroy();
    process.exit(1);
  }
}, 6 * 60 * 60 * 1000);

await client.login(process.env.DISCORD_TOKEN);

discord.py

The Python SDK is synchronous, so the periodic check runs in a thread to keep the event loop free.

# pip install sunlicense discord.py
import asyncio, os, platform
import discord
from sunlicense import SunLicense

sunlicense = SunLicense(base_url="https://api.sunlicense.com", token=os.environ["SUNLICENSE_API_KEY"])

def check_license():
    """Returns None when the bot may run, or the rejection code."""
    try:
        r = sunlicense.validate(os.environ["LICENSE_KEY"], host=platform.node())
    except Exception:
        return None                                   # unreachable: fail open
    if r.valid or r.status != 400:
        return None
    return r.data.get("code") if isinstance(r.data, dict) else "REJECTED"

class Bot(discord.Client):
    async def setup_hook(self):
        self.loop.create_task(self.recheck())

    async def recheck(self):
        while True:
            await asyncio.sleep(6 * 60 * 60)
            code = await asyncio.to_thread(check_license)
            if code:
                print(f"License rejected ({code}). Stopping.")
                await self.close()
                return

code = check_license()
if code:
    raise SystemExit(f"License rejected ({code}). The bot will not start.")

Bot(intents=discord.Intents.default()).run(os.environ["DISCORD_TOKEN"])

A few details worth getting right:

• The machine id. The examples use the host name to stay short. Something that survives reboots and moves better is an id you generate once and keep in a per-user folder; the template below does that.
• The API key in the build. While developing, SUNLICENSE_API_KEY comes from your own .env. In the copy you sell, write it in at build time (a bundler define or a generated settings file), so buyers only add their LICENSE_KEY and DISCORD_TOKEN.
• Logs. Print keys masked (AX8P-XXXX-XXXX-XXXX), never in full. Buyers paste logs into support tickets.

Don't want to write it? The discord.js template has all of this built in, plus an offline license file, a /license status command, analytics and a sealed core that only opens with a valid license. There's also a JDA template for Java bots.

Step 4: give buyers a role in your support server

Most bot sellers run a Discord server for support and updates, and want a "Customer" role for people who paid. Doing that by hand doesn't scale and never gets undone after a refund.

The SunLicense Discord bot does it from the license itself:

1. Connect your server from the dashboard's Discord page and run the setup command it gives you.
2. /sunlicense roles picks the role for each product (or one verified-buyer role for any product).
3. /sunlicense panel posts a claim panel. A buyer presses Claim a license and enters their key and purchase email: both must match, so a leaked key alone can't be claimed.

The role follows the license: given on claim, removed when the license is revoked, suspended or expires, given back on reinstate. Buyers can see their licenses with /my-licenses, reveal their key privately and free a machine slot themselves.

Your staff get notifications too, including a key-sharing alert when a license is refused because all its machines are in use, with a button to suspend it.

What this doesn't do

A license check stops casual sharing: the zipped folder, the key passed around a server. Someone determined can still edit the check out of a JavaScript or Python bot. Obfuscating your release and sealing a core part of the bot (so it only runs after a valid check) make that slower; they don't make it impossible. Pick the effort that matches what the bot earns.

Get started

The Discord bot, the SDKs and store integrations are on every SunLicense plan, including the free one (3 products, 100 licenses, no credit card). The page for Discord bot sellers shows the whole setup, and the Discord guide lists every command.

A license key. Each buyer gets their own key, the app checks it when it starts, and you can switch a key off after a refund or when it shows up on a forum. This guide shows how to add one with a single prompt to the same agent that wrote the app, how the agent proves it works, and what you should still check by hand.

I build SunLicense, the licensing service used as the example here. The checklist at the end applies to any licensing setup.

What a license check needs to do

Before you let an agent loose on it, know what "done" looks like. A good license check:

Agents are good at writing this code. They are less good at knowing which edge cases matter (fail open, masked keys, which token belongs in the app), which is why the prompt spells them out.

Step 1: get the prompt

There are two ways, depending on whether you have an account.

Without an account: open sunlicense.com/prompt and press Copy. The agent creates a guest account for you, so you can try the whole thing before signing up.

With an account: open Products → your product → Setup and choose Copy prompt. That version is tied to your account and that product, with the parts your plan includes switched on.

The prompt holds no keys. It's a set of instructions: what to build, the rules to follow, and what success looks like at each step.

Step 2: paste it into your agent

Open the project in Claude Code, Cursor, Codex, Copilot, Windsurf or Gemini CLI and paste the prompt. It's written to run without asking you questions: where it has to choose, it picks a sensible default and lists it at the end.

Here is what it does, in order:

1. Works out what the project is: language, what kind of product (desktop app, CLI, bot, web app, plugin), how it starts, where it keeps settings and how releases are built.
2. Installs the SunLicense CLI and runs sunlicense init, which creates (or finds) a free account, a product, an API key and one test license, and writes SUNLICENSE_API_KEY and SUNLICENSE_LICENSE_KEY to a gitignored .env.
3. Adds the license check with the official SDK for your language (Java, JavaScript, Python, .NET, PHP, Lua) or a plain HTTP call: once at start-up, stop the paid features on a rejection, keep working when SunLicense is unreachable.
4. Adds protection: seals a small piece of the app (the "core unlock") so it only opens after a valid check, logs an ownership notice with the key masked, and reports modified copies.
5. Adds anonymous product analytics (versions, OS, runtime), with a setting your users can switch off.

The core unlock matters more for AI-built apps than it sounds. Anyone can open your app in their own editor and type "remove the license check". If a small part of the app is sealed and only a valid license opens it, deleting the check leaves a copy that doesn't run.

Step 3: let it prove the check works

Code that compiles isn't code that works. The prompt makes the agent test the check against the real service with the test license, in three moves:

1. Run the app (or a short script that calls the check): it reports the license as VALID.
2. sunlicense licenses suspend test@example.com --yes, run it again: rejected with SUSPENDED.
3. sunlicense licenses reinstate test@example.com, run it again: VALID.

That sequence is the one that catches real bugs: a check that always says yes, one that caches the first answer forever, or one that treats a network error as a rejection. If a step gives the wrong answer, the agent fixes the code and repeats it.

It finishes with a short summary: which files changed, where the customer's key goes, how a release build gets the API key, and how to issue, suspend and reinstate licenses.

Step 4: check these five things yourself

The agent did the work; you own the result. Ask it to show you each of these, or read the diff:

1. The right key is in the app. Apps use an API key (slk_...), which can only validate licenses. A personal access token (slp_...) can manage your whole account and belongs to the CLI and your agent, never in a build you ship.
2. No secrets in git. git status and git diff show no .env, no full license key and no API key. Logs print keys masked, like AX8P-XXXX-XXXX-XXXX.
3. Unreachable is not a "no". Run the app once online, then turn off your Wi-Fi and start it again: it should keep working and log that it couldn't check (the sealed core stays open for 7 days after the last valid check). Only an answer like SUSPENDED or REVOKED should stop it.
4. The built file works outside your project folder. Copy the release build somewhere else and run it with the test key. A build that only works because it finds your local .env is a build your buyers can't run.
5. Your users can find where the key goes. A settings screen, a config file, an environment variable: whatever your kind of app uses, say so in the README and the purchase email.

Step 5: connect your store

The last piece is issuing keys when people pay. Connect your store on the Integrations page: Stripe, Gumroad, Lemon Squeezy, Payhip, Ko-fi, itch.io and others. For Gumroad and Lemon Squeezy the key in the buyer's receipt is the key your app validates; for a Stripe Payment Link the buyer is sent to a page that shows their key. Refunds revoke the key automatically.

What this doesn't do

Licensing stops casual sharing: the forwarded download, the key posted in a Discord server, the copy running on ten machines. It doesn't make your app uncrackable. Someone with a valid license and enough time can still pull it apart. The sealed core and tamper reports make that slower and visible, not impossible. Set your expectations there and you'll be happy with the result.

Try it

The free plan covers 3 products and 100 licenses, with the SDKs, store integrations and the prompt included, and no credit card. If you're shipping something you built with an agent, the SunLicense page for AI-built apps shows the whole flow, and the docs for assistants are at docs.sunlicense.com/guide/ai-assistants.