Building and Selling a MIFY Plugin

This is the most technical of MIFY’s earning routes and the narrowest audience. It is also the one that compounds best: a plugin that becomes the standard way to connect a widely used service keeps earning without further work, and is very hard to displace once people’s workflows depend on it.

If you write code, this is where your advantage over other operators on the platform actually lies.

What a plugin is

The canvas ships with 126 native nodes across 24 categories. A plugin adds more — a custom node, an adapter, an integration with a service nobody has connected yet. Once published to the plugin marketplace, it is available to every platform user.

The tooling is a small CLI:

npx mify-plugin init my-plugin
npx mify-plugin dev
npx mify-plugin publish

Initialise, develop against a live instance, publish. That is the whole lifecycle.

Choosing what to build

This decision matters far more than the code, and it is where most plugin effort is wasted.

Good candidates share three properties:

A service many people already use that is not yet connected. Reach, not novelty.
A dull, well-documented API. Boring integrations are the ones people need daily and nobody enjoys writing.
Something you have personally needed. If you hit the gap while doing client work, somebody else is hitting it too.

Poor candidates:

A wrapper around something the platform already does well. There are 126 native nodes and 140+ providers already — check before building.
An integration with a service you find interesting but few businesses pay for.
Something that only makes sense inside your own workflow. That is a workflow, not a plugin.

The strongest signal is having already built it badly by hand for a client, using generic HTTP blocks and a pile of data transformation. That pain is the specification.

What separates a used plugin from an ignored one

The code is rarely the hard part. What determines adoption:

Sensible defaults. A node that works with three fields filled in gets used; one that requires eleven gets abandoned on the canvas.
Errors that say what to do. “401 Unauthorized” is a dead end. “The API key is missing the read:items scope — regenerate it with that scope enabled” is support you did not have to provide.
Output shaped for the next block. Return a clean, predictable structure. If every user must add a transformation block after yours, the design is wrong.
It handles the boring failures. Rate limits, pagination, expired tokens, partial responses. This is what people are buying — the fact that they never have to think about it.
Documentation with one complete example. Not a parameter table. A worked case from trigger to result.

Testing before you publish

mify-plugin dev runs against a live instance, which is the only way to find the things that matter. Work through:

The empty case. No results, empty list, null field.
The large case. Pagination past the first page. Most integrations break here.
The unauthorised case. Expired token mid-run.
The rate-limited case. What your node does when the service says slow down. Retrying blindly is worse than failing clearly.
The wrong-input case. Somebody wires a string where you expected an object, because on a visual canvas they will.

That last one is specific to this environment. In code, types stop people. On a canvas, a user connects any output to any input and finds out at runtime, so your node has to fail with an explanation rather than a stack trace.

Publishing and pricing

Published plugins appear in the marketplace for all users. Pricing follows the same logic as solutions — one-off or subscription.

Subscription is usually right here, and for a reason specific to integrations: the service you integrate with will change. APIs get versioned, auth methods get deprecated, endpoints move. A plugin is a maintenance commitment, and one-off pricing funds none of it. Buyers understand this; a plugin that has visibly been kept current is worth more than a cheaper one that has not been touched in a year.

Price low at first. A plugin’s value comes from being depended on, and dependence starts with being tried.

The strategic case for going free

Worth considering seriously: publish it free, and earn from what it makes possible.

A widely adopted free plugin makes you the recognised expert on that integration. The services and jobs that follow — “we need this connected properly, and you wrote the connector” — are frequently worth more than the plugin’s licence revenue would have been, and they arrive without you selling anything.

This is a real trade rather than an obvious answer. Licence revenue is passive; consulting is not. But if you are early to a platform, distribution is worth more than margin, and free is the fastest way to get it.

Where this fits with the other routes

Plugins pay worst at the start and best over time. That makes them a poor first route and an excellent second one:

Start with services and jobs — they pay now and they show you which integrations are missing.
Build the plugin for the gap you kept hitting.
Package the surrounding work as a solution.

By that point you have three income shapes from one body of knowledge, which is a considerably more stable position than any of them alone.