On this page · 5 min
The filter
Most software was never written.
Two filters decided what got built. The problem had to be shared by enough people to pay for it. And it had to reach someone who could code.
Agents removed both filters. The person with the problem now builds the solution.
A problem with one user is enough.
Small software
Small software has one owner and a few users. The person who wrote it is usually one of them.
It can generally be run on a single or a few machines.
It generally works for a few minutes a day and waits the rest.
Individuals and teams use small software a lot. Think of tools for workflow automations, dashboards, data visualizations, personal trackers, simple databases, custom notifications, and internal agents.
There is an unlimited demand for such tools.
The same two filters held these back: a tool for eight people never justified a week of a developer's time, and the eight people could rarely build it themselves. An agent builds the same tool in an afternoon.
The numbers
GitHub went from 233 million public repositories at the end of 2022 to 395 million today. In 2025 alone it added 36 million new developers, one every second.
Commits tell the sharper story. Developers pushed about a billion commits to GitHub in 2025, a record. By May 2026 the platform was taking in 275 million commits per week, on pace for 14 billion in a year.
Most of that new software is small software. This is what the world builds when the filters are gone.
The wrong computer
The software already works. It works on your laptop.
For anyone else to use it, it has to run on a computer that stays on and has an address. Getting it there is the work: pick a host, write a Dockerfile, configure the port, arrange TLS, copy the state, keep the process alive.
The tool has four users. Nobody does that homework for four users. The tool stays on the laptop and stops when the lid closes.
Built for a million users
Everything between your laptop and a server exists for a good reason. When a million people depend on your software, a bad change hurts a million people. The complexities that have been introduced in this workflow include
[explain the process from laptop to server but then also related to the 'server' offerings. bare machines vs managed services of which the latter is horrible performance, not configurable, and expensive ...]
A tool with four users pays the same cost and gets nothing back. It inherits the process without the risk that justified it.
The big clouds are good at their job, and their job is big software.
The machine
We believe the unit of small software is a running machine.
A Google Doc is a live object with an address. You never mail the file. You share access to the thing itself, and the thing is always its current version.
Software should be the same kind of object. The running machine is the software. Everything you do to the software, you do to the machine.
So give every small tool a computer of its own. A real machine, with a disk, a kernel, and a URL.
Build where it runs
The agent works on the machine that serves the URL. It edits the software that is already running. You refresh the page and it is different.
There is nothing to deploy, because nothing has to move. The version that people use and the version being worked on are the same running program.
Share the machine
Sharing is an operation on the machine.
Send the URL and a colleague uses the tool. Give them access and they work in it directly. Or they fork a copy and continue on their own. Credentials are wiped when you share a machine. Your colleague gets the tool, and none of your keys.
Living software
Software that runs where it is written keeps changing while people use it.
Someone asks for a column. The agent adds it. The page refreshes. There was never a version, a release, or a rollout. There is only the machine, and what it does today.
Spreadsheets have worked this way for forty years, and that is why every team still runs on them. Small software keeps that behavior and adds everything a spreadsheet cannot do.
What we are building
boxd gives every piece of small software a computer of its own. A real Linux machine with a persistent disk, a dedicated kernel, and an HTTPS URL. It suspends when idle and costs almost nothing while it waits, so owning fifty of them is normal.
Because the machine is the unit, everything you want is an operation on a machine. Take a snapshot before a risky change and roll back when it goes wrong. Fork one when a colleague wants a copy. Point your own domain at it, load it with secrets, connect it to GitHub, Slack, or Linear, and let your machines reach each other on a private network. And the boxd CLI is installed inside every machine, so machines can create machines: software running on one box can spin up another, hand it work, and reach it by name. Everything the CLI does, the API does too, so all of it can be automated.
It is a real computer with root, so anything that runs on Linux runs on it.
An agent on the machine can configure everything: install the database, schedule the job, point the domain at the result. When it needs a second machine, it creates one. Agents work best when they control their whole environment, and here that environment is the entire computer.
Most software was never written.
It is being written now, by the people who needed it all along. It needs a computer of its own.
That is what we build.
