The Age of One-User Software

I built Relay with Codex because I wanted coding agents to reach me on my phone. It is a simple notification bridge, with a skill that agents can use to send progress updates and Live Activities. When an agent needs input from me, it can request it through the same service.

Relay has a SwiftUI app and a small server that currently runs on my Raspberry Pi. It does a specific job for me. That was enough reason to build it.

I also bought ESP32 devices for home automation and asked Codex to build me a home control panel. Within a couple of hours, I had three working devices. They now sit around my home, where I use them to control lights, scenes, and music.

These projects are changing my first response to a software need. There may already be a suitable tool, but I increasingly want to build what I have in mind before researching what is available. I enjoy the process. For a personal project, that enjoyment is part of the value, even when building is not the quickest option.

The minimum viable audience gets smaller

Every custom tool has a cost: the time to build it, check it, and keep it working. The benefit has to justify that effort. When development takes less time, smaller problems can cross that threshold. A tool that saves a few people a recurring frustration may be enough.

The minimum viable audience might be a family, a small interest group, or one person. They can judge whether the software is worth having by what it does for them, without needing thousands of other people to want the same thing. With one user, talking to myself now counts as user research.

Personal software already exists. People have built it with spreadsheets, scripts, and small databases for decades. I see agents as a way to make that practice more accessible and extend its scope. More people may be able to turn a particular need into a usable application, although describing and checking the result still takes work.

Choose the features that fit

Codex has also built an app to help my parents watch movies, and it is working really well. They are not very comfortable with technology, and downloading movies for them takes some effort. The app uses my Raspberry Pi with SSD storage for the movies, and a small SwiftUI app showing what is available to download, what is already downloaded, and a way to watch it.

Existing software has to serve people with different needs. A feature that I never touch might be the reason someone else chose it. But the settings and choices that support those needs can also make a simple task harder to find.

A broader media app might already do everything my parents need. My interest is in putting those few actions directly in front of them. Similarly, my home panels bring the controls I want together in the places where I use them.

Fit can also mean combining things. I might want the download behaviour of one tool and the simple library view of another. A custom app could bring that combination together. It need not reproduce everything either tool offers, and it can use existing components where they already do the job.

A small audience makes feedback direct. If my parents cannot find a downloaded movie, I can change that part of the app. The support team is also expected to attend family dinners. Fewer features could also mean less code and lower resource use, but neither follows automatically. Agents make extra features easier to add too. Keeping the app small remains a choice.

Small apps will need somewhere to live

I have a head start here: a Raspberry Pi that acts as my own server, with Cloudflare Tunnel and domains I control. Deploying another app is easy for me because that setup already exists. About a year ago, almost all my services ran on it, with some orchestration to manage them. Relay still runs there today.

Not everyone has a server ready to use, or wants to learn how to run one. Some personal tools can live entirely on a phone or laptop. For those that need a server, getting an agent to build the app leaves another question: where does it go, and who keeps it running?

Even a simple website can come with a large collection of packages and dependencies. Depending on the tools, the build environment could take a gigabyte of disk space, even if the finished site is small. That is not a gigabyte of memory needed to serve each site, but it shows how much machinery can sit behind a small result. Shared dependencies and build tools can reduce that overhead.

This raises an interesting question for cloud hosts. Much of the cloud conversation has been about helping an application scale to more users. What happens when an app only ever serves one family? The scale may move from users per application to the number of separate applications, each with its own dependencies, data, and maintenance needs. Many could sit idle for most of the day.

My prediction is that this will create more demand for hosting with low idle costs and less manual administration. Small services can share infrastructure or run only when needed, but deployment, access control, backups, and updates also need to be easy to manage. A useful app for a handful of people should not require each person to become a server administrator.

Someone still has to look after it

Generating an app does not establish that it works. For the movie app, I need to check what happens when a download stops, storage fills up, or the server is unavailable. I also need to control access and keep the software updated.

For tools that hold personal records, protecting data and checking that backups can be restored matter just as much as the interface. These responsibilities belong in the decision to build. Sometimes an existing, maintained tool will still be the better choice.

Commercial and open-source tools remain useful options. But my own starting point is changing: I can try building the thing I want, and enjoy making it fit. Relay and the home panels already have a place in my daily life. An app that helps my parents watch a movie is now working well too. None of them needs a larger audience to be worth having.