Hello everyone,
I would like to share a thought about how we build value around a design tool today: shipping a plugin, or driving the tool with an agent (MCP server, skills, a local or hosted LLM).
This is a subject I am directly concerned about. I build plugins, and I spend most of my time trying to make plugin building reachable for more people, so that anyone can cover one precise use case and keep control over what it costs. I would welcome your feedback.
TL;DR
A plugin is an act of service: the load is carried once, by its author, for everyone who installs it, and the cost sits at the start. An agent is a way to build through your own prism: immediate, personal, shaped exactly as you think, and billed every time you run it. My working hypothesis is agents to explore, plugins to produce. What I would like to discuss is where each of us draws that line, and what it changes for an open-source tool like Penpot.
If you want the longer version, here are the slides of the 10 minute talk.
Context
For years, packaging value for a design tool meant one thing: a plugin. A manifest, an embedded UI, storage, auth, versioning, a catalogue listing, sometimes monetisation. It is a real product, with a real cost, and it requires code.
Since Penpot shipped its MCP server, and since agent skills became usable by people who do not write code, a part of that value can exist without any plugin at all. You describe an intent, the agent reads the document, calls the API, applies the change. No UI to maintain, no release cycle, no catalogue listing.
I have tested both sides: plugins in production, and full design tasks driven from a conversation through the Penpot MCP server. Both work. They do not cost the same thing, and they do not belong to the same people.
The problem
The two paths have opposite cost curves.
A plugin is expensive at the entry: reading the API, handling the sandboxed environment, designing an interface that fits inside the editor. It requires a developer, or a designer who codes. Once it exists, the marginal cost is close to zero, and the evolutions become product decisions (UX plus dev).
An agent setup is cheap at the entry and open to almost any profile, but the cost grows with usage, because it is billed by token. The more specific the request, the more you pay, and weak framing multiplies redundant calls.
Running a local model changes that equation, and this is where I see real value: no metering, data that stays home, a bill you can predict. It does not erase the cost, it moves it to infrastructure. I opened that path in another thread here, about local open-source tooling in design schools, and I went deeper into it in this article, as a complement.
Two other points I do not want to skip:
- Sovereignty: unless the model runs locally, design data, internal know-how and business logic leave the perimeter. A self-hosted Penpot connected to a hosted LLM is only half sovereign, and that matters precisely for the organisations that chose Penpot for its openness.
- Accessibility of the practice: making an agent evolve means writing and reading skills, in a dense markdown format. It is more open than code, but it is not effortless. For people with attention difficulties or neurodivergent profiles, long instruction documents are a real barrier, and I think we should say it out loud.
My current take
Shipping a plugin is an act of service. Someone carries the load once, and everybody else stops carrying it. The work is packaged, documented, maintained by its author, and it outlives the person who installed it.
Using an agent is the opposite movement. You build through your own prism, you shape the process exactly as you think, and it fits you because you wrote it. It is powerful, and it is personal.
The image I keep coming back to: having a piece of furniture made for your space, versus buying it at IKEA. The commissioned piece costs more upfront, someone else solved the hard parts, and it lasts. IKEA is convenient, immediate, you assemble it to your own taste, but durability is not part of the deal, and the price you avoided at the start comes back later.
Neither is wrong. They answer different moments.
What I am exploring
A sequence rather than a competition:
- Agent plus MCP as the exploration ground: you automate, you test, the process takes shape, and nobody has to commit to a product yet.
- The process stabilises: it becomes named, documented, repeatable, boring in the good sense.
- The plugin as the production ground: you encode the stabilised process, with a predictable cost, an interface anyone can use, and data that stays inside the perimeter.
Applied to Penpot, this feels worth discussing here, because Penpot sits in a rare position: open-source, self-hostable, with an MCP server already shipped, and a catalogue still small enough that every contribution is visible.
Some open questions
Thank you for reading. Nothing here is settled, this is an open reflection rather than a conclusion.
- Is it still worth building a plugin for a use case an agent could cover with a few skills? Where do you personally draw the line?
- For plugin authors: has agentic usage already changed your roadmap, your scoping, or the way you write your documentation?
- Does an MCP layer grow the plugin ecosystem or replace part of it? My hypothesis is that it grows it, by revealing which processes deserve a real interface.
- How do we keep extensibility accessible to non developers, without pushing everyone into a metered dependency?
- Has anyone here paired a self-hosted Penpot with a local model to drive real design work? What worked, what failed, and what did the setup cost you in time?
)
