Around the 40-engineer mark, something predictable happens. One team has a slash command for PR reviews. Another has a hook that runs the safety checklist before destructive database migrations. A third has wired the incident runbook as a context loader so the on-call engineer does not have to remember where it lives.
None of them know the others built the same thing last quarter.
This is the Claude Code duplication problem. It looks like a tooling problem. It is actually an org design problem.
What a Claude Code plugin marketplace actually is
A Claude Code plugin is a packaged unit of shared tooling: slash commands, hooks, skills, and MCP server configurations bundled with an owner field and a version. A marketplace is the internal catalog that surfaces them with a one-command install and clear ownership records.
Without a marketplace, a 50-engineer Australian org typically ends up with 8 to 15 independently maintained Claude Code configurations across squads. Some documented, most not. When an engineer moves teams, they lose their tools and rebuild from scratch. The cost of that duplication, at $120–$150/hr for a senior engineer spending half a day rebuilding shared commands, adds up faster than most platform leads expect. That same duplication produces inconsistent behaviour: the PR checklist the backend team runs is not the one the platform team runs, and no one knows which is current.
The four elements a functioning marketplace needs:
A plugin registry. Usually a private GitHub repo with one folder per plugin, a plugin.json manifest defining name, version, and owner.
An install command. One script that writes the plugin's slash commands and hooks into the engineer's local .claude/settings.json.
An owner field per plugin. Every plugin has a named human or team responsible for it. Ownerless plugins die.
A CHANGELOG. Engineers need to know what changed when they pull an update. Without one, updates become risky and engineers pin to old versions.
That is the whole shape. No portal, no admin UI. A repo, a script, and a discipline.
The three plugins to seed it with
Start with three, not ten. Ten plugins at launch means ten plugins to maintain before the pattern is proven. The right three for most Australian engineering teams in 2026:
A code-review plugin. Your PR checklist covering security, test coverage, and breaking-change flags, surfaced as a /review slash command. Engineers run it before requesting review, not after. For most Australian development teams on GitHub, this cuts review turnaround noticeably because reviewers stop re-flagging the same structural issues on every PR.
A database-migration plugin. Safety hooks that block destructive SQL without an explicit confirmation flag, plus the migration template your team actually uses.
An incident-response plugin. The runbook as a context loader. The on-call engineer runs /incident start and Claude loads the runbook, relevant service docs, and the post-mortem template. During an active incident, having that context loaded in seconds versus hunting through Confluence for 8 minutes is the difference that matters.
Three plugins. Each with a named owner. Each installed in week one. The marketplace is established before anyone has time to debate governance.
One practical note: build the install command before the first plugin ships, even if it just copies three files. Engineers will not contribute to a marketplace they have to manually configure to use.
The Three-Gate Review Model
Governance is where most internal marketplaces either choke or rot. Choke: the platform team reviews everything, contribution rate drops to zero within six months. Rot: anything lands, and eventually someone ships a plugin that writes to production without authorisation. Have the governance model ready before you open the repo to contributions. The Three-Gate Review Model keeps both failure modes at bay:
Gate 1: Read-only, no MCP. Slash commands and skills that read context and generate output only. Auto-approved on PR merge. Low risk, high contribution volume.
Gate 2: Write hooks or local MCP. Any plugin that writes to a local filesystem, edits config, or runs shell commands. Requires one platform team review before merge.
Gate 3: Remote MCP writes. Any plugin that writes to a remote system: Jira, GitHub, Confluence, a database. Requires platform team review plus a security sign-off.
The contribution flow: engineer drafts the plugin in a personal fork, opens a PR against the marketplace repo, and tags the correct gate in the PR template. Gate 1 PRs merge on approval from any senior engineer. Gate 2 and Gate 3 require the platform lead.
This is not bureaucracy. This is the minimum structure needed to prevent a plugin from exfiltrating customer data in an org subject to the Australian Privacy Act (1988). Write access plus misconfigured scope is a real attack surface, not a hypothetical one.
When not to build one
If your engineering org has fewer than 25 engineers, skip the marketplace infrastructure. A single shared .claude/settings.json committed to the monorepo handles that case without the overhead of a registry, review process, and install script.
The other reason to skip it: your platform team does not have capacity to own the gate review function. A marketplace with no gate-keeper is worse than no marketplace. Orphaned plugins accumulate like technical debt, except they run as Claude hooks against live systems, not as dead code sitting quietly in a repository.
If your org is not yet sure where it sits on the Claude Code adoption curve, the AI Readiness Assessment helps clarify where shared tooling would actually save time before you invest in building the infrastructure to support it.
What it costs and what it returns
A 50-engineer Australian org typically spends $35,000–$60,000 in platform team time building and seeding a v1 marketplace: roughly four weeks of one senior engineer's time at $120–$150/hr fully loaded, plus a week of plugin development for the starter set and a day of governance documentation. That is the full cost to standing up a functional v1.
Return comes from two directions. First, eliminated duplication: when three squads stop building the same PR-review slash command, you recover $80,000–$120,000 per year in senior engineer time at $120–$180/hr fully loaded. Second, convention enforcement: the same migration safety hooks running across every engineer materially reduces incidents from unapproved schema changes. That second return is harder to quantify and consistently underestimated by teams that focus only on the build-cost payback. For teams in Melbourne or Sydney sizing this work, our AI Automation Services include marketplace setup, plugin development, and governance design.
The orgs that get this right treat the marketplace as infrastructure, not a side project. Before committing to the build, run the numbers through our ROI Calculator to check whether the investment pencils out at your headcount. It usually does.
