We’re building a plugin marketplace platform, and we’re going to do it in public.
Not a marketplace for Forge’s own plugins (though it powers that too). A platform that lets any application run its own governed plugin marketplace. The kind of infrastructure that Shopify, Atlassian, and Figma have spent years and millions building internally, extracted into something reusable.
Why This Exists
Every mid-to-large SaaS company eventually wants an extension ecosystem. The pattern is predictable: customers ask for integrations you can’t prioritise, partners want to build on your platform, and your product team realises that opening up to third-party developers could unlock value faster than building everything in-house.
But the infrastructure that powers plugin marketplaces is almost always treated as proprietary. There’s no shared playbook. Most teams reinvent the same things from scratch: plugin submission flows, review queues, security scanning, version management, installation scoping. The result is years of engineering investment before the ecosystem even launches.
We think that’s unnecessary.
What We’re Building
A reusable marketplace platform with a deliberate separation of concerns:
- Marketplace handles the catalog, policy, governance, and discovery. This is the layer that knows about plugins as products: listings, versions, reviews, enforcement, analytics.
- Forge handles the plugin build pipeline, static analysis, and runtime execution. This is the layer that knows about plugins as code: what they do, whether they’re safe, how they run.
- Host apps integrate via SDK to resolve installed plugins in their own UI. This is the layer that knows about plugins as features: where they appear, what they contribute, how users interact with them.
The best-in-class platforms like Shopify and Attio are already showing the way, demonstrating that opening your product to third-party developers creates compounding value. But until now, the infrastructure behind those ecosystems has been proprietary. We’re building the reusable layer that makes this accessible to any product team with the ambition to go there.
Architecture Choices
We decided early that the marketplace should be opinionated about governance but flexible about how host apps integrate. The API is multi-tenant by design. Each marketplace is its own isolated world with its own plugins, developers, policies, and review queues.
The tech stack is intentionally boring: Rails 8 (API-only), PostgreSQL, and Solid Queue. The complexity lives in the domain model, not the infrastructure. Plugin governance, version state machines, policy evaluation, enforcement workflows, installation scoping, trust hierarchies. That’s where the interesting problems are, and that’s where we’re spending our energy.
Building in Public
We’re going to share the journey here as we go. Architecture decisions, things we got right, things we got wrong, open questions we’re genuinely uncertain about. Not polished case studies after the fact, but real-time updates from the build.
Some of what’s coming:
- How we’re handling plugin governance as automated, policy-driven infrastructure
- The AI-native operations model (MCP server for AI agents to operate the marketplace)
- Plugin lifecycle design: version state machines, installation scoping, contribution declarations
- Developer experience in a governed ecosystem
- Multi-tenant architecture for serving multiple host applications
- Security as a first-class concern: static analysis, version drift detection, supply chain defence
What We’d Love to Hear
If you’re building products, thinking about extensibility, or have experience with plugin ecosystems from any angle, we’d love your input:
- What would you look for in a plugin marketplace platform if you could avoid building one from scratch?
- How much of the Shopify/Atlassian marketplace model do you think is reusable vs. deeply product-specific?
- What parts of our build process would you want visibility into?
This is the first in a series. More to come.