I wanted to share some of the backstory behind our thinking on plugin marketplaces and extensibility infrastructure, because it didn’t start with Forge. It started at Mural.
The Mural Years
As Head of Platform (and later Ventures) at Mural, I was responsible for creating the extensibility strategy, designing the extensibility architecture, and building the systems that powered plugin development, distribution, and governance. Forge came to the fore as the runtime, buildtime, and governance layer, with the first version of our plugin marketplace administration tools.
The impact was immediate. Our team could go from idea to production in days, not the quarters that core product teams were battling with. We used the plugin system to ship validated learning that directly informed the product discovery-to-delivery pipeline and decision gates. First AI features went out through the extension layer. Multiple variants of new concepts, all running in production, all without touching the core.
Then things took a significant turn when we were among the first to introduce generative AI into the developer workflows. The plugin system became our defensive guardrails. It gave us a sandbox for untrusted AI-generated code, a governance model for reviewing what came out, and a way to ship AI-powered capabilities without exposing the core application to risk.
What We Were Up Against
We weren’t operating in a vacuum. Competitors like Miro and Figma had more mature extensibility strategies at the organisational level. They’d invested earlier, had stronger ecosystem marketing, and had built developer communities that were further along.
And internally, we faced headwinds that will be familiar to anyone who’s tried to drive a platform strategy inside a product company:
- Leadership that didn’t fully grasp the value of developer ecosystems. The business case for extensibility is indirect. It’s about compounding value over time, not a feature you can point to in a sales demo. That’s a hard sell when the board wants to see pipeline impact this quarter.
- Marketing that didn’t know how to talk to developers. Developer audiences have a finely tuned sense for when they’re being marketed to versus when someone is genuinely trying to help them build. Getting that wrong doesn’t just fail, it actively damages trust.
- Organisational friction pushing against ecosystem thinking. When the default mental model is “we build features, users consume them,” shifting to “we build a platform, the ecosystem creates value on top” requires a cultural change that goes far beyond engineering.
These weren’t technical problems. They were organisational ones. And in many ways they were harder to solve than the architecture.
What This Means for Forge Today
Forge’s plugin marketplace is still early and actively in development. But everything we’re building is informed by that experience. We’re leveraging the capability internally first, powering Forge’s own customer offering, learning as we go, and sharing those learnings openly.
The approach is deliberate: we build it, we use it in Forge, we validate it for customers, and we share what we learn along the way. The marketplace infrastructure, the governance tooling, the developer experience, all of it is being shaped by real use, not theoretical design.
Questions Worth Discussing
This topic sits at the intersection of product strategy, engineering, and organisational design. Some questions I’d love to explore with this community:
- Have you tried to introduce a platform or extensibility strategy inside a product-led company? What resistance did you face?
- How do you make the business case for developer ecosystems when the ROI is indirect and long-term?
- What’s the right relationship between a plugin system and the core product team? Collaborative? Independent? Adversarial?
Keen to hear from anyone who’s been in similar trenches.