Designing addon boundaries that survive growth

Good addon boundaries are less about folder structure and more about ownership. A feature should be able to answer three questions: who starts me, who stops me and which contracts may other packages rely on?

Start with one capability

Name an addon after the capability it owns, not the screen or scene where it first appears. Inventory, housing and quests are useful boundaries because each describes behavior and data with a coherent lifecycle.

Avoid grouping unrelated systems into a generic gameplay addon. That package becomes a dependency magnet and removes the isolation the addon model is meant to provide.

Keep the public contract small

Expose the minimum stable surface that another package needs. Internal components can change freely; public events, configuration and service interfaces require deliberate compatibility decisions.

Move shared runtime ownership into services

An addon remains the package entry point. Long-lived scene behavior belongs in component services, where s&box lifecycle and ownership are visible. This keeps initialization code short and avoids invisible global state.

When two addons need the same runtime capability, promote that capability into a focused service instead of letting one addon reach into the internals of the other.