Everything converges to one app architecture

Everything I build lately ends up with the same shape: a small core, and every feature is a plugin.

My CMS, my chat workspace, the courses, the forum. I didn’t plan it, honestly. It’s just where every product seems to end up after a few months of building with agents.

What it looks like

The CMS has a core package with about thirty feature packages next to it: QR codes, SEO, payments, a forum, analytics, and so on. A site is the core plus a list:

plugins: [seo(), redirects(), share(), newsletter(), feedback(),
          analytics(), payments({ passes: { paid: "a paid plan" } }),
          videos(), review(), staticSite()],

That’s a real site config. The core has no idea what a QR code is, and I like it that way.

The chat workspace works the same. There’s a core, and memory, schedules, usage tracking and BIM viewing are packages. Even the model providers are packages, so OpenAI is a plugin and so is Anthropic.

Deleting a feature means deleting a folder

This is the bit I care about most. When nobody uses a feature, I delete the package and take it out of the list, and that’s it. I don’t have to hunt through the codebase for all the places it hooked into, or leave half-dead code lying around because nobody dares to touch it.

Most codebases only ever grow. Stuff gets added, nobody removes anything, and every new feature has to tiptoe around the old ones. With plugins, removing a feature is as cheap as adding one, so I actually do it. tef said this years ago, and better: write code that is easy to delete, not easy to extend.

The contract is where the design goes

The core is mostly a list of places a plugin can hook into: routes, settings, database migrations, admin pages, events and tools for agents. That list is what I spend my design time on. Features come and go, but that list stays put.

A plugin brings everything it needs through those hooks, from its own tables and settings screen to its translations and tests. Nothing about it lives in the core.

Plugins don’t know about each other

The QR plugin adds ?via=qr to the link inside the code. The analytics plugin shows how people arrive at a page. Neither imports the other, and still the analytics shows your QR scans. Delete either one and the other keeps working.

This is easy to get wrong. As soon as plugins start importing each other you’re back to a tangled codebase, just with more folders.

Agents get the tools for free

Every plugin can hand tools to agents. Install the forum plugin and the agent connected to the site can read and post in the forum. Delete it and those tools disappear with it. So the agent’s abilities simply follow the feature list, and I never have to maintain a separate agent integration.

Vendors are just plugins

Because the model providers are plugins, switching AI vendor is a line in a config, not a migration project. With new models every few months, I’d say that’s worth more than any single feature.

Why this works so well with agents

An agent working on the QR plugin only needs to understand the QR plugin and the hooks. If it screws up, the damage stays in that one folder and I can throw the whole thing away and try again.

That’s how I get to go fast without breaking stuff. I try an idea as a plugin, put it on one site, and kill it a week later if nobody uses it. Meanwhile the core stays small and boring, which is what you want from a core.

The convergence

New products now start as a core plus a list of plugins, and they borrow plugins and ideas from each other. Making a new site is mostly picking what goes in the list. The chat workspace even loads Claude Code plugins as they are, so skills, commands, agents and MCP servers come in through the same door. The risky parts, like hooks, just don’t get run.

I really think this is where software is heading: a small core, well-designed hooks, and a pile of features you can add or delete without being scared of it.