Userbase 1

Small apps are getting cheaper to make than to explain.

That changes the trade-off. If I need a tiny tool for one workflow, I may not look for an app anymore. I may just generate one, use it, and throw it away when it stops working.

A userbase of one.

Not a market. Not a community. Just one person with one annoying problem.

The small tool becomes disposable

Most software used to need scale. Build once, sell or share many times. That shaped the software itself. A task manager had to fit thousands of people, so it became generic. A utility had to justify maintenance, documentation, releases, support.

AI coding tools weaken that logic.

If the cost of making a small tool drops far enough, the tool no longer needs to be good for many people. It only needs to be good enough for this job, this folder, this afternoon.

That is useful. It is also messy.

Ego-forks

Open source has always allowed forks, but most forks were not worth the trouble. You had to understand the code, make the change, keep it building, and maybe argue with upstream later.

Now the social cost of contributing can be higher than the technical cost of forking.

Do not like a workflow? Fork it. Feed it to an agent. Make the version you wanted. Never publish it. Never maintain it for anyone else.

That produces many small private variants. Some will be useful. Most will rot quietly.

The debt does not disappear

A generated script that works once is not the same as a system.

APIs change. Operating systems update. Dependencies break. Authentication flows expire. The little tool that solved a problem in March may be dead by October.

For some tools, that is fine. Delete it. Generate another one. The code was never the valuable part.

But this only works if the tool did not take the data with it.

State and logic

Throwaway software needs non-throwaway data.

If a generated app stores everything in an opaque database, invents its own file structure, or rewrites metadata badly, it is not disposable. It is a trap with a friendly interface.

The logic can be temporary. The state cannot.

So the rule is simple: keep data in boring formats. Markdown. JSON. CSV. Normal folders. Files that can be inspected without the app that created them.

The generated tool should be a lens over the data, not the place where the data lives.

File-first by necessity

This is one reason I keep coming back to file-first systems. If the tool breaks, the files remain. If the UI disappears, the archive still makes sense. If the script was a bad idea, delete the script.

FileFirst is one version of that principle: metadata in plain JSON next to the files it describes, with SQLite and Markdown projections on top. Useful layers, but disposable layers.

The same applies to this Garden. It is Markdown first. Quartz can change. The hosting can change. The pages remain files.

The useful version

Userbase 1 is not a grand new era. It is mostly a permission slip to build smaller, rougher tools.

That is enough.

Make a tool for one job. Use it. Keep the data outside it. Throw the tool away when it stops earning its place.

Code can be temporary.

The archive should not be.

See also: FileFirst, How This Garden Grows, Erledigt