Search before you commission anything
Three catalogues are worth searching before you spend money. Hangar is the PaperMC team's own plugin repository, covering Paper, Velocity and Waterfall. Modrinth lists plugins alongside mods and data packs, and filters by platform and exact game version. SpigotMC's resource section is the third, and it also carries paid premium plugins.
Search for the behaviour as well as the name. "Daily playtime limit" turns up things "Varo" does not, although "Varo" is worth searching too: at the time of writing, Modrinth lists a Varo plugin claiming support from 1.8.9 through to 26.2.
Judge a candidate by its listing, not its download count. A plugin that does most of what you want through its config usually beats a commission, and if it is open source, a small addon built on its API usually costs less than a rewrite. Commission when the rules are genuinely yours, when the only candidate is abandoned on an old version, or when it must integrate with something nobody else uses.
- Support stated for your exact version, not a range such as 1.13+
- A recent update, and issues that are being answered
- Public source and a stated licence, so an author leaving does not strand you
- Behaviour you can change in config rather than in code
- No licence check that phones home, and nothing that can be switched off remotely
Datapacks and Skript: the routes in between
Between installing something ready-made and commissioning something bespoke sit two cheaper routes, each right for a particular kind of request.
A datapack is vanilla Minecraft's own customisation layer: a folder or zip with a pack.mcmeta file, placed in the world's datapacks folder. It can define recipes, loot tables, advancements, predicates, functions and world generation, it runs on vanilla and on Paper, and players install nothing. It cannot reach outside the game, so there is no database, no Discord and no permissions plugin, and its pack format changes between Minecraft versions.
Skript is a plugin that lets admins write server behaviour as English-like .sk files in plugins/Skript/scripts, reloaded with /sk reload. It requires Paper, not Spigot, and supports the last 18 months of Minecraft versions counted from its newest release. It suits short, server-specific rules an admin wants to read and tweak. Once a script grows state, storage, menus and edge cases, you are maintaining a program either way, and a Java plugin gets compile-time checking and the full Paper API rather than whatever Skript and its addons expose.
Plugin, mod or resource pack: who installs what
A plugin lives only on the server, and players join with an unmodified client. A Fabric or NeoForge mod lives on the server and on every player's machine, pinned to a loader and a Minecraft version on both sides.
What matters over a year is who has to act when something changes. With a plugin, one person updates the server and the plugin, and players notice nothing. With a mod, every update is a coordinated move: a new server build, a new client build, and every player on it the same evening, or they cannot connect. That is why the same feature costs more to build as a mod, and keeps costing more to keep.
So check whether you really need a mod. A plugin can pair with a server resource pack, which the vanilla client downloads when it joins, and the server can require it and disconnect anyone who declines. Through the item_model component, an ordinary item can then carry its own model and texture, with its behaviour supplied by the plugin. That covers many "custom item" requests. It cannot add what the vanilla client has no concept of, such as new keybinds, or blocks and entities that need their own client code. Those genuinely need a mod.
What a brief needs before anyone can fix a price
A fixed price is a promise to deliver specific behaviour for a specific sum, so every decision the brief leaves open is risk someone has to price. Handed a vague brief, a developer can pad the quote, bill by the hour or guess, and a guess is the start of an argument. You do not need a specification document. Plain sentences are fine if they cover the following.
Version: write the number, never "latest". Since 2026 Minecraft versions are numbered by year and drop, so 26.1 then 26.2, with hotfixes after a further dot, and 26.1 was the first release to require Java 25. Paper's /version command prints the exact build. If you run Folia, say so first, because its own page warns that it breaks most public plugins.
Behaviour: trigger, then action, then what the player sees. "On death, the player becomes a spectator, their teammate is told, and after 30 seconds they are kicked" can be built. "Death is handled properly" cannot.
Edge cases: a disconnect or a restart halfway through, a full inventory, a player who is offline when something happens to them.
Permissions: one node per command, and who holds it by default. A Paper plugin declares each default as op, not op, everyone or nobody, so choose rather than inherit.
Configuration: what admins can change without a new build. Every key is also something to test.
Persistence: what survives a restart, what resets and when, and where it is stored.
Other plugins: name each one, and say whether yours must refuse to start without it or simply use it when present. Paper calls these depend and softdepend.
Acceptance: a handful of sentences of the form "when I do this, that happens". They become your test script, and later the definition of broken.
What Varo is, and why the rules need writing down
Varo is a German Minecraft event format. It began in 2014 as a YouTube project with around forty German YouTubers, and the name is short for Vanilla Roleplay. Teams of two start spread around a single Nether portal at spawn, the last team standing wins, and death is final: in the original events a dead player was banned from the server by a plugin and could only follow along through their teammate's episodes.
The distinctive part is rationed playtime. The original rules capped episodes at 15 minutes, and another ruleset had the server kick players after exactly 15 minutes and required an episode every day. Rule breaches earned strikes, and three strikes meant disqualification. The spawn portal was the only way into the Nether, and traps that killed a player as they logged in were banned.
Other communities have rerun the format, and the rules drift each time. One community ruleset allowed 30 minutes a day, enforced by plugin, with extra time while a fight was still going. It shrank the border with each elimination once fewer than half the players remained, and daily from the seventh day. It published the coordinates of any team that avoided a fight for 15 days, banned enchanted golden apples and several potions, and gave each team one locked chest. None of that is canonical Varo, which is the point: there is no rulebook to hand a developer, so your brief has to be the rulebook.
Worked example: a Varo brief, written out
This brief is for a Varo event on one Paper server. Every line answers a question a developer would otherwise have to ask or guess. Your rules will differ, which is fine as long as each one is written down.
Notice what it leaves out. Recording rules, fair-play rulings and whether a fight was provoked belong to your admins. The plugin enforces what a machine can decide without argument, and a clear line there keeps the build smaller.
- Server: Paper 26.2, exact build from /version, Java 25, one server, no proxy. Permissions through LuckPerms.
- Teams: exactly two players, assigned by admins with /varo team before the start and locked once it begins. No friendly fire.
- Start: /varo start freezes everyone for a 30-second countdown. After it, players not on a team are refused entry.
- Playtime: 30 minutes per player per day, configurable, resetting at 00:00 Europe/Vilnius rather than server time. Warnings at 5 minutes and 1 minute, then a kick, and no rejoining until the reset.
- Combat: if time runs out within 15 seconds of player-versus-player damage, the kick waits until 15 seconds pass without any. Logging out inside that window counts as a death.
- Login protection: 10 seconds of invulnerability on joining, ended early if the player attacks.
- Death: 30 seconds as a spectator, then a ban from the event with a configurable message. The teammate is told, and when both are dead the team is eliminated and the server is told.
- Strikes: /varo strike <player> <reason>, admins only, logged with time, admin and reason. Three strikes disqualify the player.
- Nether: the spawn portal is the only way in. New portals will not light, and the spawn portal cannot be broken.
- Border: 3,000 by 3,000 blocks centred on spawn. From day 7 it shrinks by 50 blocks a day at 20:00 until it reaches 400 by 400, announced an hour before each shrink.
- Banned items: enchanted golden apples and potions of Strength, as a configurable list. They cannot be crafted, brewed, picked up or used.
- Persistence: teams, strikes, deaths and each player's minutes used today, in a flat file saved at least once a minute and kept across restarts.
- Admin: /varo status lists every team, its strikes and its minutes used. /varo revive undoes a death caused by a server fault. Both need varo.admin, default op.
- Out of scope: Discord announcements and a web leaderboard.
- Acceptance: a two-team rehearsal on staging covering a timed kick, a kick delayed by combat, a combat logout, a death, an elimination, a third strike, a restart mid-session and a border shrink.
How the price is fixed, and how to bring it down
Puranode quotes from the brief, as a flat price with a timeline. The category figures are floors: a custom minigame or game mode from €149, an economy, shop and ranks system from €89, an anti-cheat and moderation suite from €119, a Discord and server live sync from €69, and a web dashboard for your server from €199. They show where each kind of job starts. They are not ceilings, and not a menu to add up. The Varo brief above is a custom game mode, and the number of decisions in it, not the word Varo, decides how far above the floor the quote lands.
Seen as a list of decisions, a brief also shows where to save. Changing your mind after the quote is fine, but it is new scope and priced as new scope, so argue with the brief before you send it.
- Commands before menus. An inventory menu with pages and confirmations is an interface to design and test; a command with tab completion is not.
- A flat file before a database, unless several servers genuinely share the data.
- Configure what you will really change between events, and fix the rest.
- One server before a network. A proxy turns shared state into a synchronisation problem.
- Judgement calls to admins. A strike command is cheaper, and fairer, than automatic detection of a rule people would argue about.
Owning the code: what to check at handover
Owning the source only helps if you can use it. Puranode hands over the source with every build, but whoever you hire, check the handover while the 30 days are still running, because that is when gaps are cheapest to close.
Ask for the repository, not a zip of the final state: a Git repository with its history shows how the code got where it is and which change broke what. Ask for a build you can reproduce, meaning someone other than the author can clone it on a clean machine and produce the jar with one command. For a Paper plugin that usually means Gradle, which the Paper team uses itself, with the Gradle wrapper committed so the project pins its own Gradle version.
What is missing matters as much. There should be no Minecraft server jar in the repository, since Paper's developer documentation notes that redistributing it is against the Minecraft EULA. There should be no passwords or tokens in the code, because those belong in the config on your server. And there should be no licence check or remote switch, because you paid for code that runs without anyone's permission.
- The repository in an account you control, not only the developer's
- A README covering the build, the install, and every command, permission node and config key
- The Java and Paper API versions written down
- A list of bundled third-party libraries and their licences
- A clean build by someone other than the author before the 30 days end
Licences: what is settled and what is not
Some things are settled. Paper's licence file states that Paper is under the GNU General Public License version 3, inherited from Spigot, which inherited it from Bukkit and CraftBukkit. Skript is also GPLv3, with some contributions under MIT.
What is not settled is how far that licence reaches into a plugin that only compiles against the API and is loaded by the server at runtime. People disagree, paid plugins are sold openly, and this page will not pretend to state the law. For a plugin that never leaves your server, the question rarely matters in practice. It starts to matter once you plan to sell it, publish it or hand it to another network.
So ask the developer, in writing, which licence the code is delivered under, which third-party libraries are bundled into the jar and under what licences, and whether anything was copied from another plugin. If you intend to sell or publish, take legal advice on your own situation.
One neighbouring rule is easier to state. If the plugin sells anything for real money, read Mojang's current Minecraft Usage Guidelines first. They restrict what servers may charge for, particularly anything that gives a paying player a competitive advantage, and designing around them costs less than rebuilding a shop.
When Minecraft updates: why it is new work
A plugin is built and tested against one version. When the version moves, the code has not become wrong; the ground under it has shifted, and adapting to that is new work rather than a defect. How much work varies, and the brief can influence it.
The API is the stable layer. A plugin that sticks to the Paper API often needs little or nothing for a minor release, though Paper refuses to load a plugin whose declared api-version is newer than the server, so every build also sets the oldest version it will run on. Server internals, usually reached for something the API does not expose, are the fragile layer. When Paper switched to a Mojang-mapped runtime in 1.20.5 and stopped putting CraftBukkit classes in versioned packages, plugins that relied on those package names broke. Ask at quote time whether anything will need internals, and why.
Other ground moves too. Paper announced its hard fork from Spigot in December 2024, starting from 1.21.4, and the two APIs are slowly diverging, so build against the Paper API if you run Paper. Minecraft 26.1 moved the server to Java 25. And every plugin yours depends on has to update before yours can.
For an event like Varo, freeze the server version before the start and do not update until the end. For a plugin that must stay current, put that in the brief so it is scope rather than a surprise.
The 30 days after delivery, and how to spend them
Puranode backs every build for 30 days. What that covers is the build not doing what the brief says it does. What it does not cover follows from the same sentence: behaviour the brief never mentioned is new scope, and an update to Minecraft, Paper or a dependency is new work, quoted like any other job.
The clock starts at delivery, not at your first event, and that is the trap. A Varo plugin delivered in March for an event in June has used its 30 days before a single real player has touched it. Plan backwards instead: take delivery close enough to the event to run a full rehearsal inside the window, with real players, on the exact version you will use.
Run the acceptance lines from your brief as a script, then try to break the plugin the way players will: log out mid-fight, restart the server mid-session, run out of time while standing in lava. When something fails, report the server build, the plugin version, the steps, what you expected, what happened and the relevant log lines. A report like that can be acted on. "It is broken" cannot.