Gorewood Logs

The Future of Consumer Apps?

A friend built himself an expense app. He described it as a miniature QuickBooks that he actually likes using.

What made it magical was being able to change it while doing his expenses. He wanted a right-click action to categorize every expense from the same vendor. He added it. He wanted a way to see all that vendor's expenses together. He added that too.

Small features, discovered through use, built when they became useful.

I keep thinking about what happens when that becomes an ordinary expectation of software. You buy or install a good tool, start using it, and have an agent add the particular behavior you need.

That suggests a direction for consumer and desktop apps: a dependable core, with personal features and workflows built around it.

Claude Code is an example you can already see

Claude Code's recent addition of mods makes this concrete. Mods work in the terminal and in the Code tab of the Claude Desktop app. They can add panes and commands, change parts of the interface, and intervene in tool calls. Anthropic's documentation explicitly describes asking Claude to write one for you.

Want a view of context usage arranged the way you think about it? That's the sort of customization the interface supports. Someone else's useful addition can also be packaged and shared, without everyone needing the same setup.

The interesting part is the loop: use the tool, discover a need, describe it to the agent, and extend the tool you're already using. You don't have to maintain a fork of the whole application to add your feature.

Claude Code serves developers, so it doesn't establish how mainstream consumers will behave. But it gives us a concrete example of the relationship between a maintained product and user-built behavior.

Every feature request doesn't need to become everyone's feature

A conventional product team has good reasons to decline requests. Each addition brings interface complexity, interactions with existing behavior, support work, and maintenance.

Something essential to one person can be clutter to almost everyone else. A team that tries to accommodate everybody can end up building an app nobody finds particularly pleasant.

So people adapt. They keep a spreadsheet on the side. They copy information between apps. They memorize an absurd sequence of clicks because the software almost does what they need.

An extension system creates another place for those needs to go. Coding agents could make it much easier for the person with the problem to supply the missing behavior -- just for them.

The product team still makes decisions about the shared experience. But it can also ask: can a user add this without rebuilding our app? Can they do it without making the interface more complicated for everyone else?

That's a different way to think about saying no to a feature request.

The core has a job

The foundations still matter. In an editor, I want dependable editing, file handling, undo, and recovery. In an expense tool, I want reliable transaction handling and ways to inspect and correct mistakes.

Those are capabilities personal additions should be able to use. A custom view shouldn't need its own storage system. A new editing command should participate in undo. An expense workflow should use the application's transaction rules.

For my markdown editor, I'm thinking about the smallest editing sidecar I'd want to use every day. Then there are ideas that might be useful to some people: a particular publishing workflow, document checks, or a specialized view.

Could those be optional additions? If someone likes the editor but needs one more thing, could their agent build it without forking the application?

Their setup might become elaborate. Mine might stay simple. The shared app doesn't have to accumulate every difference between us.

Give agents something better than a sequence of clicks

There are several ways to open up an app, and they solve different problems.

Plugins can put persistent behavior inside it: a command, panel, or view. APIs and CLIs can let scripts use its capabilities in larger workflows. MCP can expose tools for an agent to discover and call.

The goal is to make useful operations available at the right level. If a workflow needs to find transactions, update categories, and produce a report, those operations should ideally be accessible directly.

Computer use can bridge gaps, especially in software we don't control. But when we're building the software ourselves, we can give agents an interface that expresses the actual work.

This is already happening beyond coding tools. Sketch supports AI-assisted scripting and plugin development. Obsidian's CLI includes commands that let coding agents reload, test, and debug plugins.

Blender is an especially good example because it already had extensive customization through its Python scripting API. An agent can turn a natural-language request into a script for creating a scene, changing objects, or automating a repetitive workflow. I'd call that a step function unlock. The power was already there; agents make it accessible without requiring the person using it to write the Python themselves, much less learn Python in the first place.

Making adaptation ordinary

There's a research tradition around this called “malleable software”: tools users can reshape as needs arise.

Ink & Switch describes an example that feels especially relevant to an editor. While writing in its Patchwork environment, the authors wanted word counts by section. They used AI to build a tool during the writing session and connected it to the existing document. Collaborators could choose whether to install it.

Extensibility has limits, though. A plugin can only reach what the host exposes. An API that omits an essential operation can leave the user stuck again. Updates can break extensions, and custom code needs appropriate access and a way to recover from mistakes. Claude's mods, for example, run with the user's permissions; they aren't sandboxed.

These are product responsibilities. Opening up an app adds work for its developer, even if it reduces pressure to implement every niche feature.

I don't know whether this favors small apps over large suites in the long run. A large suite can open itself to agents too. The distinction may turn out to be how readily the software accommodates needs its developer never anticipated.

That's the part I'd bet on. As personal customization gets easier, an app's value could increasingly include how well it supports change after someone starts using it.

“Does this do what I need?” is still a good question when choosing software.

“When I discover what I need next, can I make it do that too?” might become just as important.

Optional reading