---
title: "How to Build a Plugin Marketplace for Your SaaS Product 2026"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2026-12-26"
category: "How to Build"
tags:
  - SaaS plugin marketplace
  - developer ecosystem
  - plugin architecture
  - API extensibility
  - marketplace monetization
excerpt: "A plugin marketplace is the single highest-leverage feature you can add to a mature SaaS product. Here is how to build one that developers actually want to publish on."
reading_time: "14 min read"
canonical_url: "https://kanopylabs.com/blog/how-to-build-a-plugin-marketplace-for-your-saas"
---

# How to Build a Plugin Marketplace for Your SaaS Product 2026

## Why a Plugin Marketplace Changes Everything for Your SaaS

Shopify generates more revenue from its app ecosystem than from direct subscription fees. Figma, Notion, and Slack all credit their plugin marketplaces as key drivers of retention and expansion. The pattern is clear: when third-party developers extend your product, your users get features you could never build yourself, and your churn rate drops because switching costs multiply with every installed plugin.

But most SaaS companies get this wrong. They bolt on a half-baked "integrations page" with a dozen partner logos and call it a marketplace. That is not a marketplace. A real plugin marketplace has a developer portal, a sandboxed execution environment, a review and approval pipeline, revenue sharing, and a discovery experience that helps users find exactly what they need. Building one properly takes 4 to 8 months of focused engineering effort and costs $200K to $600K depending on scope.

We have built plugin ecosystems for SaaS products with 10K to 500K users. The companies that invest early in extensibility consistently outperform competitors who try to build every feature in-house. This guide walks you through the entire process, from choosing your plugin architecture to launching your first 50 plugins.

![Team of developers collaborating on SaaS plugin marketplace architecture at a whiteboard](https://images.unsplash.com/photo-1553877522-43269d4ea984?w=800&q=80)

## Choosing Your Plugin Architecture: Hosted vs. External vs. Hybrid

The first decision you need to make is where plugin code runs. This choice shapes your entire technical stack, your security posture, and the developer experience you can offer. There are three models, and each one comes with real tradeoffs.

### Hosted Plugins (Code Runs on Your Infrastructure)

Hosted plugins execute inside your platform, typically in a sandboxed runtime like V8 isolates (Cloudflare Workers model), WebAssembly containers, or Docker-based function runtimes. Shopify Functions, Figma's plugin sandbox, and Cloudflare Workers all use this approach. The advantage is tight integration: plugins can hook into lifecycle events, modify UI, and access internal APIs with low latency. The disadvantage is that you own the execution environment, which means you need sandboxing, resource limits, and a billing model for compute.

For most SaaS products under $10M ARR, hosted plugins using V8 isolates are the sweet spot. Tools like Extism (WebAssembly plugin framework) and Deno Subhosting let you run untrusted code safely without building a custom sandbox from scratch. Expect to spend $3K to $8K per month on compute infrastructure once you have 200+ active plugins.

### External Plugins (Code Runs on the Developer's Infrastructure)

External plugins communicate with your platform through webhooks and REST or GraphQL APIs. The developer hosts their own code on AWS, Vercel, Railway, or wherever they choose. Your platform sends events (user created an account, order placed, document updated), and the plugin responds. WordPress, Stripe, and GitHub primarily use this model.

External plugins are simpler to build from your side because you do not manage execution. But the developer experience is worse: higher latency, more complex debugging, and the developer needs their own hosting. This model works best when your plugins are backend-heavy (data syncing, workflow automation) rather than UI-extending.

### Hybrid Model (Recommended for Most SaaS Products)

The hybrid approach offers a hosted sandbox for lightweight UI extensions and frontend logic, plus a webhook/API system for backend integrations. This is what Slack, Notion, and Linear use. Developers write UI components that run in your sandbox and backend logic that runs on their infrastructure. You get the best of both worlds: tight UI integration where it matters, and developer freedom for complex backend work.

If you are building your first marketplace, start with external plugins (webhooks + API) to validate demand, then add a hosted sandbox for UI extensions in v2. This lets you ship in 3 to 4 months instead of 6 to 8.

## Building the Plugin SDK and Developer Portal

Your plugin SDK is the product you sell to developers. If it is painful to use, nobody will build plugins for your platform, and your marketplace will be a ghost town. Invest heavily here because the quality of your SDK directly determines the quality and quantity of plugins in your ecosystem.

### SDK Design Principles

Ship the SDK as an npm package (TypeScript-first) and optionally a Python package if your developer audience skews that way. Every API surface should have full TypeScript types. Include a CLI tool that scaffolds new plugins, runs them locally against a development sandbox, and handles submission to your marketplace. Look at the Shopify CLI, Stripe CLI, and Vercel CLI for inspiration. These tools set the bar for developer experience.

Your SDK should expose lifecycle hooks: onInstall, onUninstall, onSettingsChange, onEvent. Provide a manifest file (plugin.json or plugin.yaml) that declares permissions, required scopes, UI extension points, and webhook subscriptions. Developers should be able to go from "npm create your-plugin" to a running local development environment in under 5 minutes. If it takes longer than that, you will lose most prospective plugin developers before they write a single line of code.

### Developer Portal and Documentation

The developer portal needs four things: interactive API reference docs (generated from your OpenAPI spec using tools like Mintlify, ReadMe, or Fern), a getting-started tutorial that walks through building a real plugin end to end, a sandbox environment for testing, and a submission dashboard. Budget $30K to $60K for the developer portal if you build it custom, or $500 to $1,500 per month for a hosted docs platform.

Documentation is where most SaaS companies underinvest. You need code samples in every supported language for every endpoint, a changelog developers can subscribe to via RSS, and a status page showing API uptime. Stripe and Twilio have set expectations high. If your docs are just auto-generated Swagger with no examples, developers will walk away.

Consider running your developer portal on a subdomain like developers.yourproduct.com. Use Mintlify ($150/month for Pro) or Fern ($500/month) for docs hosting. Both support OpenAPI import, code sample generation, and custom branding. If you are building an [API marketplace with a developer portal](/blog/how-to-build-an-api-marketplace-developer-portal), the investment in great documentation pays for itself within the first year through reduced support tickets alone.

![Developer laptop showing plugin SDK code and API documentation for SaaS marketplace](https://images.unsplash.com/photo-1517694712202-14dd9538aa97?w=800&q=80)

## Sandboxing, Security, and Permission Scopes

Running third-party code on your infrastructure is inherently risky. One poorly written plugin can crash your servers, leak customer data, or mine cryptocurrency on your compute budget. Security is not optional. It is the foundation that everything else depends on.

### Execution Sandboxing

For hosted plugins, V8 isolates are the industry standard for lightweight sandboxing. Cloudflare Workers popularized this approach, and tools like Deno Subhosting ($0.30 per million requests) and Fastly Compute let you run untrusted JavaScript/TypeScript in isolated memory spaces with strict CPU and memory limits. Each plugin execution gets its own isolate with no access to the filesystem, network (unless explicitly granted), or other plugins' data.

If you need to support languages beyond JavaScript (Python, Go, Rust), WebAssembly (Wasm) is the answer. Extism provides a cross-language plugin framework that compiles plugins to Wasm modules and runs them with fine-grained resource controls. Execution time limits (typically 5 to 30 seconds), memory caps (128MB default), and network allowlists prevent abuse.

For heavier workloads, use Firecracker microVMs (what AWS Lambda uses) or gVisor containers. These provide stronger isolation than V8 isolates but have higher cold start times (100 to 500ms vs. 5 to 50ms for isolates). Reserve microVMs for plugins that need filesystem access, persistent processes, or multi-language runtimes.

### Permission Scopes and OAuth

Every plugin must declare the exact permissions it needs in its manifest file. Model this after GitHub's fine-grained permission system: read:users, write:orders, admin:settings, and so on. When a user installs a plugin, show them a clear consent screen listing every permission the plugin requests. Never let a plugin access data it did not explicitly request.

Implement OAuth 2.0 with PKCE for plugin authentication. Issue scoped access tokens with short expiry times (1 hour) and refresh tokens with longer lifespans (30 days). Rate-limit API calls per plugin per tenant: 100 requests per minute is a reasonable default. Log every API call a plugin makes for audit purposes. If a plugin starts behaving suspiciously (sudden spike in API calls, accessing endpoints outside its declared scopes), automatically flag it for review and notify your security team.

### Data Isolation

Plugins should never be able to access data across tenants. If a plugin is installed by Company A and Company B, the plugin's execution context for Company A must have zero visibility into Company B's data. Enforce this at the database query layer, not just the API layer. Use row-level security policies (Supabase and PostgreSQL make this straightforward) to guarantee tenant isolation even if a plugin finds a way to bypass your API middleware.

## Marketplace Discovery, Listings, and Review Pipeline

A marketplace is only valuable if users can find the right plugins quickly. The discovery experience determines whether your marketplace feels like the Shopify App Store (polished, trustworthy) or a random directory of links (useless).

### Listing Pages and Search

Every plugin needs a dedicated listing page with: a clear title and description, screenshots or a demo video, pricing information, install count, ratings and reviews, a changelog, and links to the developer's support channel. Let developers upload up to 6 screenshots and one video (hosted on your CDN, not YouTube, to avoid ads). Display the "last updated" date prominently because users rightly distrust plugins that have not been updated in 6+ months.

Implement full-text search with Algolia ($1/1K search requests) or Typesense (free, self-hosted). Add category filters, sorting by popularity/recency/rating, and curated collections ("Best plugins for project management," "New this month," "Staff picks"). The homepage of your marketplace should feature 3 to 5 curated collections, not just a raw list of every plugin. If you have already built an [integration marketplace](/blog/how-to-build-a-saas-integration-marketplace), you can reuse much of the listing and discovery infrastructure.

### Review and Approval Pipeline

Every plugin submission should go through automated and manual review before appearing in your marketplace. The automated step runs static analysis on the plugin code (check for known vulnerabilities using Snyk or npm audit), verifies the manifest file is valid, runs the plugin's test suite, and checks for compliance with your branding guidelines. This catches 70% of issues without human involvement.

For manual review, assign a reviewer from your developer relations or security team. They should test the plugin in a staging environment, verify that it does what the description claims, check for UI/UX quality, and confirm that permission scopes are appropriate (a simple calculator plugin should not request write:users access). Target a 48-hour review turnaround. Shopify aims for 5 business days; you can do better if your volume is under 50 submissions per month.

Create three review tracks: new submissions (full review), minor updates (automated only if no new permissions), and major updates (full review). This keeps the pipeline fast for bug fixes while maintaining security for significant changes.

### Ratings and Trust Signals

Allow users to leave star ratings (1 to 5) and written reviews. Require that reviewers have installed the plugin for at least 7 days to prevent fake reviews. Display a "Verified" badge for plugins built by your company or trusted partners. Show install counts, but be honest about the numbers.

## Monetization: Revenue Sharing, Pricing Models, and Billing

Your marketplace needs a monetization strategy that works for you, your plugin developers, and your end users. Get this wrong and developers will not bother publishing, or users will resent being nickel-and-dimed for basic functionality.

### Revenue Share Models

The industry standard is a 70/30 split: the developer keeps 70% of revenue, and you keep 30%. Apple, Google, Shopify, and Salesforce all use this model (Shopify recently moved to 85/15 for the first $1M in revenue, which is generous). For a new marketplace with under 100 plugins, consider offering 85/15 or even 90/10 to attract early developers. You can adjust the split later as your marketplace matures and the distribution value increases.

Some marketplaces charge a flat listing fee instead of or in addition to revenue share. Salesforce AppExchange charges a $2,600 annual listing fee plus 15% revenue share. This model only works if your marketplace has significant distribution power. For most SaaS products, start with pure revenue share and zero listing fees.

### Plugin Pricing Models

Support at least three pricing models: free (developer uses the plugin to drive traffic to their own product), one-time purchase ($10 to $200 for utilities and tools), and subscription ($5 to $99/month for feature-rich plugins). Let developers set their own prices within guardrails. Freemium (free tier with paid upgrades) is the highest-performing model in most marketplaces because it reduces the friction of first install.

Build your billing system on Stripe Connect. It handles multi-party payments, automatic revenue splitting, tax compliance, and payouts to developers in 40+ countries. Stripe Connect costs 0.25% + $0.25 per payout on top of standard processing fees (2.9% + $0.30 per transaction). For a plugin selling a $29/month subscription, the total fees work out to roughly $1.40 per transaction, which comes from the developer's 70% share.

### Free Plugins and Strategic Value

Do not underestimate free plugins. They drive marketplace adoption, increase your platform's feature set at zero cost to you, and create a habit of browsing and installing plugins. Encourage free plugins by highlighting them in discovery, featuring them in onboarding flows, and offering premium placement to developers who publish high-quality free tools. Many successful plugin developers start with a free plugin to build reputation and then release paid plugins once they have an audience.

![Analytics dashboard showing SaaS marketplace revenue metrics and plugin performance data](https://images.unsplash.com/photo-1460925895917-afdab827c52f?w=800&q=80)

## Technical Implementation: Database Schema, APIs, and Frontend

Let us get into the concrete technical decisions you will face when building the marketplace infrastructure. The architecture below assumes a hybrid plugin model with a Next.js frontend, a Node.js or Python backend, and PostgreSQL as the primary database.

### Core Database Schema

You need at minimum these tables: plugins (metadata, version, status, developer_id), plugin_versions (semver, changelog, code_bundle_url, manifest), installations (plugin_id, tenant_id, installed_at, settings_json, status), reviews (plugin_id, user_id, rating, body, created_at), and developers (user_id, payout_account_id, verified_status). Add a plugin_events table for analytics: track installs, uninstalls, activations, errors, and API calls per plugin per tenant.

Index aggressively on plugin status, category, and rating for marketplace search queries. Use a materialized view for the "popular plugins" ranking that refreshes every hour (calculating popularity from install count, retention rate, and recent review sentiment). Store plugin code bundles in S3 or Cloudflare R2, not in the database.

### Plugin Lifecycle APIs

Your API surface needs these endpoint groups: Plugin CRUD (create, read, update, archive) for developers, Submission and Review (submit version, get review status, respond to review feedback), Installation (install, uninstall, update, configure) for end users, Execution (invoke plugin, send event, get plugin response) for your platform's runtime, and Marketplace (search, browse, get listing, get reviews) for the storefront.

Use GraphQL for the marketplace storefront API (complex nested queries for listings with reviews, developer info, and install stats) and REST for the plugin execution and lifecycle APIs (simpler request/response patterns). If your product already uses tRPC, extend it with new routers for marketplace functionality. Version your APIs from day one: /v1/plugins, /v1/installations. You will need to make breaking changes, and versioning lets you do so without breaking existing plugins.

### Frontend Components

The marketplace storefront is a standard e-commerce-style UI: browse page with filters and search, listing detail page, install flow with permissions consent, and a "my plugins" management dashboard. Build it as a section of your existing product UI, not a separate site. Users should be able to discover and install plugins without leaving your product.

For the developer portal, build a separate Next.js app (or a dedicated section of your main app) with: plugin submission wizard, version management, analytics dashboard (installs, revenue, errors, API usage), and payout history. The developer portal is where you compete for developer attention, so invest in a polished experience. If you need guidance on building [API-first product platforms](/blog/how-to-build-an-api-as-a-product-platform), the principles translate directly to marketplace APIs.

## Launching Your Marketplace and Growing the Developer Ecosystem

Building the marketplace is half the battle. The other half is getting developers to actually publish plugins and users to install them. You face a classic cold-start problem: users will not browse an empty marketplace, and developers will not build for a marketplace with no users.

### Pre-Launch: Seed the Marketplace

Before your public launch, you need 15 to 25 plugins in the marketplace. Build 5 to 8 first-party plugins yourself (these demonstrate what is possible and fill critical functionality gaps). Then recruit 10 to 15 design partners from your existing customer base and the broader developer community. Offer them free premium accounts, priority review, co-marketing, and early access to your SDK. Companies like Zapier, Atlassian, and HubSpot all seeded their marketplaces this way.

Run a private beta with 50 to 100 users who actively use your product. Get their feedback on discovery, installation flow, and plugin quality before opening to the public. Fix the top 10 complaints before launch.

### Launch Strategy

Announce on your blog, email list, social channels, and Product Hunt. Write a "Building on [Your Product]" blog post series featuring your design partners and their plugins. Host a launch webinar demonstrating 3 to 5 flagship plugins. Offer a launch promotion: waive revenue share for the first 3 months (developers keep 100% of revenue) or provide $500 in marketplace credits for the first 50 developers who publish a plugin.

Target these metrics for your first 90 days: 50+ published plugins, 20%+ of active users have installed at least one plugin, average plugin rating above 3.5 stars, and median review turnaround under 48 hours. If you are not hitting these numbers, the problem is usually SDK friction (too hard to build), review bottleneck (too slow to publish), or discovery (users cannot find relevant plugins).

### Ongoing Ecosystem Growth

After launch, invest in developer relations. Hire a DevRel engineer (or assign an existing engineer part-time) to maintain documentation, answer developer questions, write tutorials, and speak at conferences. Run a plugin hackathon quarterly with cash prizes ($5K to $10K total) to drive new submissions. Publish a "Plugin of the Month" feature on your blog and in your product's onboarding flow.

Build an analytics dashboard for developers that shows installs, active users, revenue, churn, and error rates. Developers who can see their plugin growing are motivated to keep improving it. Developers flying blind will abandon the platform. Send weekly digest emails to developers with their key metrics.

The long-term play is creating a self-sustaining ecosystem where top plugin developers earn meaningful revenue ($5K to $50K per month), which attracts more developers, which attracts more users. Shopify, Salesforce, and HubSpot all reached this flywheel after 2 to 3 years of consistent investment.

If you are serious about building a plugin marketplace that becomes a competitive moat for your SaaS product, we can help you design the architecture, build the SDK, and launch the ecosystem. [Book a free strategy call](/get-started) and we will walk through your product's extensibility opportunities together.

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/how-to-build-a-plugin-marketplace-for-your-saas)*