For most of the history of software, an application existed because enough people wanted it to pay for the time it took to build. A tool that only one person needed usually didn’t get written, unless that person happened to be a programmer with a lot of spare evenings. Everyone else adapted to whatever the market offered.
That has changed. With modern LLM coding tools, a person with a clear picture of the application they want can build it, even if they will be its only user. I think of it as custom software on demand: not a product with a market, but a tool made for one person’s way of working. I’ve been building software this way for most of this year, and I think it is one of the more important things these tools make possible.
Software built for the average#
Software sold to many people has to serve all of them, so it ends up shaped around the average of its users. The symptoms are familiar: settings screens with hundreds of options, menus full of features you’ll never touch, and workflows designed for someone whose needs only partly overlap with yours. None of that is bad design. It is what happens when one program has to fit thousands of people.
The cost falls on everyone who isn’t average. You learn where the software hides the one thing you need, you work around the steps that don’t fit, and you sometimes juggle two or three programs because no single one covers your case. For a long time, that was simply the price of using software you didn’t write, because writing your own was out of reach for most people and not worth the time for most programmers.
What changed#
What made custom software expensive was the building: turning an idea into thousands of lines of working code, then packaging it so it actually runs. LLM coding tools have made that part cheap. A program that would once have taken months of evenings can now take days, and much of the work that used to stall personal projects (build systems, file formats, network protocols, the plumbing that has nothing to do with the idea) is exactly the work these tools handle well.
What they didn’t make cheap is knowing what you want. That part was always the user’s, and now it is most of the job.
A slicer for two printers#
My most recent example is deli, a 3D printer slicer that I wrote about recently. I have two printers, an Elegoo Centauri Carbon and a Voron, and I was using two or three slicers to drive them, each with a settings window I had to hunt through. I wanted one slicer that lives in my shell, where a print is a small text file holding only the settings I changed, and getting from a model file to a running print takes two commands. No company would build that for a person with my two printers and a preference for the terminal; the market for it is roughly me.
So I built it with Claude Code. The first commit landed on the morning of October 2. By that evening deli had PrusaSlicer’s engine linked in, a converter for OrcaSlicer’s printer presets, and the commands that make it a slicer. The next day it printed a calibration cube on the Elegoo, and that evening a Benchy in PETG-CF with a pause for a filament change. By the fifth day it had a CI job that slices a test cube on every printer in an OrcaSlicer release, wheels for Linux and macOS, and a one-line installer. I made the decisions and tested the results on real printers; Claude wrote the C++ binding, the settings converter, the printer protocols, and a build system that took a long string of fixes to run on GitHub’s machines. None of that plumbing is what deli is about, and in the past any piece of it could have been where a side project like this stalled.
Software for my own life#
deli is the newest of these, not the first. My homelab is full of software with exactly one user.
The clearest case is my health coach. Every health app wants to coach you, but none of them know you: they give advice based on population averages. Mine knows my baseline. I log meals and measurements by sending a message from my phone, Claude estimates the macros and puts each reading in the context of my own history, and everything lands in a time-series database and dashboards I control. It is built around my lab results and my questions, and it would be a strange product for anyone else.
Around the same time I built three small apps in a month: a Spanish translator that replies in audio, a bot I can ask about my health data from any room in the house, and a camera alert system that decides for itself what’s worth telling me about. Each took under an hour to have running, and an AI assistant wrote most of each one. Since then, the assistant I talk to every day has grown the same way, one personal need at a time: it keeps the books for my LLC, triages my email, manages the grocery list, and tells me when something in the homelab breaks. None of those features came from a product roadmap. Each one exists because I wanted it and could say clearly what it should do.
What you still have to bring#
Building software for yourself with an LLM is not the same as asking for an app and getting one. The person with the idea still does the work that matters most, and in my experience it comes down to four things.
The first is a precise picture of the application: not only what it does, but how it should feel to use and what it should leave out. “A slicer” is not a vision. “A print is a directory, and the only settings I see are the ones I changed” is.
The second is writing that picture down. A model starts every session fresh, so a vision that lives only in your head drifts. For deli, the repository had a PLAN.md on the first morning with a section of decisions that opens “Do not reopen these without a reason”: a set of shell commands, no REPL and no TUI, state in a text file in the current directory, and PrusaSlicer’s engine rather than Orca’s fork. A few days later the decisions about what users see got their own file, DESIGN.md, which says that a change going against any of its principles needs a good reason, written down there. Principles like asks only when someone is there to answer, no surprises and nothing changes under you are how deli stayed shaped like the thing I had in mind instead of drifting toward a generic slicer.
The third is saying no. When code is cheap, the danger isn’t building too little; it’s building too much. A model will happily add any feature you mention, and each one is something you have to understand and live with. Personal software has an advantage here: it only has to fit one person, so it can stay small. Several of deli’s commits remove things. On the second day, deli send --print refused a PETG-CF print with PETG-CF loaded in the printer, because my config still named PLA as the default. The check came out, and the principle it left behind is defaults save typing; they never get in the way. Later a list of filaments on hand went too, with the commit message “deli is not an inventory, and the list would always be out of date.” Neither feature was broken. They just weren’t what I wanted.
The fourth is checking it in the real world. You are the user, the product owner and the tester, and a model will cheerfully describe untested code as working. One of deli’s principles is honest about what has been checked: its printers page lists which of OrcaSlicer’s 1,001 printers convert and slice a test cube, and says plainly that slicing a cube is not printing well and which printers have actually printed deli’s output. That list is short. Software for an audience of one still has to work for that one.
No market required#
The part I find most freeing is that none of this needs anyone else. A product needs users, a roadmap and a reason to keep growing. Software for yourself only needs to do what you wanted. If it does that, it has succeeded, whether or not anyone else ever runs it.
This is how Tony Stark worked in Iron Man. When he wanted something new, he didn’t go shopping for it; he described it to JARVIS, and JARVIS built it with him: the designs, the simulations, the parts. Stark wasn’t selling JARVIS, and as far as we know he never open-sourced it either. It was a tool for one person, shaped around how that person worked. It’s also worth noticing who did what. JARVIS was enormously capable, but the ideas were always Stark’s. JARVIS never decided what the next suit should be. That division of labour is the one I described above, and for a long time it was science fiction.
Now that it isn’t, it changes which ideas are worth acting on. The question used to be whether enough people wanted something, or whether I had enough free time to absorb the cost. Now the question is simpler: does any off-the-shelf solution fit my need? If one does, I use it. If none does, I build my own.
Shared in case it helps#
Sharing software built this way costs almost nothing, so I do. deli is open source, it installs with one line, and I hope people with more than one printer, or a fondness for the shell, find it useful. If nobody else uses it, that’s fine. It already does what I built it to do.
I expect a lot more software to be made this way: shaped around one person’s needs, built in days, and shared on the chance it helps someone with similar needs. It comes with a responsibility. I didn’t type most of this code, but every decision in it is mine, and so is every claim it makes about what has been tested. Custom software on demand puts the person with the vision in charge, and being in charge includes owning the result.