Every server owner hits the same wall. The plugin you need doesn't exist, the closest match on the marketplaces does 80% of what you want, and the remaining 20% means either learning Java or paying a freelance developer $50-200 and waiting a week for the first version.
There's now a third option: describe the plugin in plain English, and let AI build it.
What building a plugin with Foundry looks like
Foundry is a desktop app that builds real Paper plugins - the same kind of plugin you'd get from a developer, written in Java against the actual Paper API. The difference is how it gets written:
- You describe the plugin. "A /home system: /sethome saves your location, /home teleports you back with a 30-second cooldown. Make the cooldown configurable, and give players a welcome message when they join."
- The AI writes it. Commands, event listeners, the config file, plugin.yml, permissions - real, readable Java you fully own. It works from the actual Paper API source code for your server version, not guesses.
- One click to test. Foundry boots a local Paper test server with your plugin installed, then launches a test client that joins it automatically. You're standing on your test server watching your plugin work minutes after describing it.
- Admin like a real console. A built-in server console lets you run
op,gamemode,give- anything you'd type into a normal server console - so you can test permission-gated features properly.
When it works, you take the .jar from the build folder and drop it into your real server's plugins/ directory. It's a standard Paper plugin with zero Foundry dependency - it runs on Paper, Purpur, and other Spigot-compatible forks.
Why "it validates the boring parts" matters
If you've ever commissioned or downloaded a half-finished plugin, you know the classic failure modes: a command that's declared but does nothing, an event listener that never fires because it was never registered, a config file that ships empty. These don't cause errors - they just silently don't work.
Foundry checks for exactly these after every build. Declared commands must have handlers. Listeners must actually be registered. Config usage must have defaults. The AI fixes what the validator catches before you ever load the plugin.
What kinds of plugins can you build?
Anything that lives in the Paper API, which covers the large majority of what servers commission:
- Custom commands - teleports, kits, info commands, admin utilities
- Event mechanics - join/leave messages, death handling, block protection, custom drops
- Configurable gameplay - cooldowns, multipliers, toggles your staff can tune in config.yml without touching code
- Permissions-aware features - different behavior for players, VIPs, and staff
- Scheduled tasks - announcements, timed events, cleanup jobs
Iteration is where it really beats commissioning: "make the cooldown per-world" or "add a sound effect on teleport" is one sentence and a minute of rebuild - not a new invoice.
Getting started
Download Foundry free, create a new project, and pick Paper as the platform with your server's Minecraft version (1.20 through the latest are supported). Setup is one click - Foundry handles the JDK, Gradle, and the Paper API automatically.
Then describe your first plugin. Start small - a custom join message is a nice first build - and work up from there. Your test server is one click away the whole time.