MustUse | Hosted plugin ecosystems

The Problem

Blockstudio just went open source. It's the best templating layer for WordPress blocks. But there's no ecosystem around it — no directory, no marketplace, no way for developers to publish and distribute Blockstudio-native block plugins.

Every author ships their own update mechanism, their own licensing, their own distribution. It's fragmented and expensive to maintain.

Meanwhile, Troy is open source infrastructure for exactly this: plugin registries, update servers, and package distribution. But it needs a hosted product to reach non-technical operators.

The Product

MustUse.com is Troy deployed as a managed cloud service. Any product ecosystem (Blockstudio first, others later) gets:

A dedicated server on their own domain, fully rebranded
A headless registry API for browsing, searching, downloading, and updating packages
An author portal for plugin/theme developers
A package update server that speaks native WordPress
Tenant-controlled policies for reviews, revenue, and access

How It Works with Blockstudio

Troy provides the pipes. The tenant owns the marketplace.

1. Tenant Setup

Blockstudio signs up as a MustUse tenant and gets a branded registry at marketplace.blockstudio.dev.

2. Author Submission

Block authors submit scoped plugins to the registry. Each plugin is a thin WordPress plugin whose only dependency is Blockstudio.

3. User Install

Site owners browse available blocks from within WP Admin and install with one click. Updates flow natively through WordPress UI.

The Headless Advantage

MustUse intentionally ships no frontend. The registry API is the product. This means Blockstudio can build a browsing UI inside their plugin settings page, a standalone marketing site, or a WP Admin page that feels completely native.

The tenant controls the experience. MustUse controls the infrastructure.

┌─────────────────────────────────────────────────┐
│  Tenant Frontend (Blockstudio's UI)             │
│  - In-plugin browser / standalone site / admin  │
└──────────────────────┬──────────────────────────┘
                       │ REST API
┌──────────────────────▼──────────────────────────┐
│  MustUse Cloud (Troy daemon)                    │
│  ┌────────────┐ ┌──────────┐ ┌───────────────┐  │
│  │  Registry  │ │  Update  │ │    Author     │  │
│  │  API       │ │  Server  │ │    Portal     │  │
│  └────────────┘ └──────────┘ └───────────────┘  │
│  ┌────────────┐ ┌──────────┐ ┌───────────────┐  │
│  │  Package   │ │  License │ │    Tenant     │  │
│  │  Storage   │ │  Engine  │ │    Config     │  │
│  └────────────┘ └──────────┘ └───────────────┘  │
└──────────────────────┬──────────────────────────┘
                       │ WordPress Update API
┌──────────────────────▼──────────────────────────┐
│  WordPress Sites                                │
│  - Blockstudio (mu-plugin or plugin)            │
│  - Scoped block plugins (standalone or dep)     │
│  - Native update UI integration                 │
└─────────────────────────────────────────────────┘
                    

Next Steps

Phase 1

Define the Troy Registry API

Establish the contract and endpoints every tenant integrates against.

Phase 2

Build the Blockstudio update client

The mu-plugin that checks the MustUse registry for available and updated packages.

Phase 3

Spec the block package format

The standard for what a scoped Blockstudio plugin looks like (headers, dependency declaration, build variants).

Launch

Ship a proof of concept

10 Blockstudio block plugins published to a MustUse-hosted registry, fully installable from WP Admin.