I kept the project split into small parts bc it makes the plugin easier to work on if i need to change something . The main freeze logic sits in FreezeManager, while commands and listeners only deal with input from the server. So when a player runs /freeze, or when Paper fires an event, those classes dont need to know how the whole system works. They just ask the manager what to do. It keeps the code cleaner and avoids one huge main class that becomes annoying to edit. I also avoided using a static singleton for everything. Passing the needed classes through constructors is just easier to test, easier to replace, and less messy when the plugin grows , thats how i create a plugin. U can see exactly what each class depends on without digging through global state. Frozen playrs are saved in data.yml , and that's all , i dont think i need to mention something else. If this was going into a bigger setup , I'd change a few things. For a single Paper server, data.yml is fine. For a network with multiple servers, i would move the storage to SQL or Redis so every server sees the same freeze state. Redis pub or sub would also be useful for instantly syncing freeze and unfreeze actions across the network but i think everyone knows that :) . I’d also move disk writes away from shutdown only saving. Saving async after changes, with some debounce, would be better if the server crashes. The current setup is simple and lightweight but since it was just a "test" i think it can prove my knowledge