There is a script on my machine that renames a folder of camera files into the date format I actually think in, strips the ones below a size threshold, and drops the rest into a year/month tree. It is forty lines long. It has no tests, no README, and barely any error handling. If the folder is empty it throws an ugly stack trace, and I have never once fixed that, because I am the only person who will ever run it and I know not to point it at an empty folder.
I would have been embarrassed to ship that to anyone. That is precisely why it is one of the most useful things I own.
For most of my career, building software meant building it for someone else. Even the internal tool, the throwaway, the quick fix: somewhere there was another person whose judgement the thing had to survive. A colleague who would inherit it. A reviewer. A future maintainer, often me, who would open it in eighteen months and curse. The cost of that audience was baked into everything: you wrote the comment, added the guard clause, gave the function a name that would mean something to a stranger, because a stranger was always implied. Software was a social object before it was a useful one.
The quietest thing the coding agents changed is that they removed the stranger.
The bar that used to be there
Think about what it actually took to get a small tool built, before. Not a product. A tool. The thing that would save you twenty minutes a week and that no vendor would ever sell because the entire addressable market is you.
You had to want it badly enough to spend an evening on it yourself, or badly enough to ask someone. Asking meant scoping. Scoping meant a conversation about whose time, on whose backlog, owned by whom afterwards, justified against what. And the arithmetic almost always came back the same: the tool was too small to be worth a person's afternoon, so it went unbuilt, and you kept doing the thing by hand.
But notice the quiet assumption buried in "spend an evening on it yourself." That was only ever an option if you could write the thing at all. For most people it wasn't. The economic bar (is this worth someone's time) sat on top of a second, harder bar that the first one usually hid: can you personally do this, ever, at any price. For a tool only you will use, you can't outsource your way past that one. There's no budget to throw at it, no team to assign it to; it's you or nobody. So the person who wanted the trip planner but couldn't write a line of code didn't lose on the arithmetic. They never reached the arithmetic. They were stopped at the door by a skill they didn't have and had no reason to spend two years acquiring for a single tool they'd use for a fortnight.
That second bar is the one I find more interesting, because it's the one AI actually demolished rather than merely discounted. I'm a case study in it whether I like it or not: twenty years around data systems and I still can't write or much CSS by hand. Three years ago that sentence ended the conversation about whether I'd ever ship a web app of my own. Now it doesn't even slow it down. What used to require a specific, hard-won, years-deep skill now requires AI plus the two things that were always cheap to find in a person who actually wanted the thing: creativity and drive. The skill hasn't become unnecessary in general; plenty of work still needs it. It's become unnecessary as a precondition for trying.
The personal-tool version of that gap was always worse, because a personal tool can't even pretend to a business case. There is no "this saves the team forty hours a quarter" to wave at. It saves you, specifically, a small and unimpressive amount of friction, and the only person you have to justify it to is yourself, but the cost of building it was high enough that even self-justification failed. So you didn't build it. You filed it under would be nice and got on with your week.
What changed is not that the tools got more important. They are exactly as trivial as they always were. Two bars fell at once. The price of building dropped far enough that the justification step, the whole social apparatus of deciding whether a thing is worth making, simply evaporated for this category. And the skill bar that used to sit underneath it, the one that decided whether you could build the thing at all, fell with it. You don't justify an omelette to anyone before you make it, and you don't need a culinary degree to scramble eggs. Personal software is allowed to be that casual now, and open to people for whom it was never an option before.
1
2
3
- The machine you actually use, not the one you'd put on a slide.
- A gadget that solves exactly one problem, and no one else's.
- Notes kept in whatever format you happen to think in.
The category no product will ever serve
There is a particular kind of tool that lives in the gap between what you do and what software is built to do. It fits your habits, your data, your one weird workflow. It assumes things no general product can assume, because a general product has to work for a hundred thousand people and yours has to work for one.
I have a handful of these on my bench, and I offer them as evidence rather than as a portfolio, because the point is how unremarkable they are. Share started as a way to collect and enrich links the way I think about them, not the way a bookmarking product imagines I do: short tracked URLs, AI summaries, reading lists, the specific small workflow I kept reaching for and never finding. The Server Metrics collector and its companion Task API exist because I wanted lightweight observability on a couple of Windows boxes where standing up a real monitoring stack would have been absurd overkill: a PowerShell script that writes rolling CSVs, and a localhost-only HTTP wrapper around a whitelist of scheduled tasks. Nobody asked for any of them. Nobody else uses them. That is not a flaw in the work; it is the entire design.
A product can't build the tool that assumes your folder structure, knows your three clients by their quirks, and skips the step you never need because you never have that problem. The moment it has two users it has to generalise, and generalising is where the fit goes. The audience of one is the only audience small enough to build for exactly.
The market of one
The tools worth building for yourself are precisely the ones no vendor will ever ship, because their entire addressable market is a single person with a single weird habit. That used to make them unbuildable. Now it makes them yours.
If you can't think of what to build
The hardest part, if you've never done this, isn't the building. It's that the part of your brain that generates ideas has spent years being told that's not worth it, and it's gone quiet. So here is a starter list. None of these are clever; most people just need a few concrete examples before their own backlog of half-noticed annoyances starts surfacing.
Build a small game. A clone of something you loved, a one-screen arcade thing, a daily puzzle only you play. The feedback is instant and visual, which makes it a wonderful first build: you see exactly what your instruction produced the moment you produce it, and a bug isn't a silent failing test, it's a ball going through a wall in front of you.
Make graphics or a simulation, the kind of thing that's pure curiosity with no use case at all. I rebuilt Eric Graham's 1987 Amiga Juggler raytracer as a single browser file over a weekend, driving the translation from the recovered Amiga C source through : chrome spheres on a checkerboard floor, the demo that once convinced people the Amiga was a serious graphics machine. GlyphBlaster is the same impulse pointed sideways: a tool that rebuilds photographs out of text glyphs, scanlines and painterly splatter, useful to no one and a delight to watch work. Neither solves a problem. That was never the requirement.
Write the script that finally sorts the Downloads folder, the one with eleven hundred files named image (47).png and three years of installers. Or the desktop equivalent, the "Mess" folder everyone has, the digital junk drawer. Sorting it by hand is the kind of chore you've been not-doing since 2021; an afternoon with an agent turns it into a script you run once a month and forget.
Wire up a home-automation experiment that no product packages the way you'd want it. The light that comes on only when it's both dark and someone's home. The notification that fires when the freezer door's been open ninety seconds. The thing the commercial hub almost does but not quite, in the specific way that matters in your specific house.
Build a one-off travel companion for a single trip. A little app for you and your family going on holiday: the itinerary, the confirmation numbers, the offline map of the one neighbourhood you'll actually walk, the packing list shaped like your packing list and nobody else's, a currency converter pinned to the two currencies you care about this fortnight. You'll use it for ten days and never again, and that's fine. It cost you an evening, not a subscription.
Notice what that last one isn't: small. A trip-planning app for a family is a real piece of software with real moving parts, and three years ago it would have been a genuine project, a reason to either pay for something close-enough or just use a spreadsheet and grumble. The audience of one doesn't mean trivial. It means unjustified by anyone but you, and that's a different axis entirely. The Juggler reconstruction was a weekend of fairly involved work; it's still a thing built for an audience of essentially one. The cost of building collapsed across the board, at the top end as much as the tiny one, which means the things now worth making for yourself range from a forty-line file-renamer up to software that would once have needed a budget and a sign-off.
You don't write a spec for an omelette
The cooking comparison is doing real work here, so let me lean on it.
When you cook a meal only you will eat, you don't write it down. You don't measure. You taste, adjust, and stop when it's right for you, by a standard only you can apply. If it's slightly too salty you'll know for next time and you won't tell anyone. Nobody reviews the omelette. There is no omelette retrospective.
Personal software gets to be that casual, and the casualness is the feature, not a corner cut. My file-renaming script throwing a stack trace on an empty folder is not technical debt. Debt implies a creditor, and there isn't one. It is a sharp edge on a tool I keep in a drawer that only I open, and I know which way to hold it. The energy I would have spent rounding that edge off, for the benefit of a user who does not exist, is energy I got to keep.
This is the part that takes some unlearning, especially if you've spent years being paid to build the careful kind. Every instinct says handle the empty case, name it properly, write the comment. For a personal tool those instincts are miscalibrated. They were trained on a world with an audience in it. Remove the audience and most of them stop applying.
The temptation to make it "proper"
The counter-pull is real, and I fall for it more than I'd like to admit. You build the little thing, it works, and then some professional reflex wakes up and says: make it proper. Add config. Add a settings file. Make it handle the cases it'll never hit. Give it a name and a home and a structure, as though it were going to be inherited.
Most of the time that reflex is wrong, and wrong in an expensive way. The tool was already finished, and you're about to spend three more evenings finishing it again to a standard nobody required. The discipline of building for one is knowing the thing is done the moment it works for you. Not when it survives every input. Not when it handles the empty folder. When it does the job you built it for, on the inputs you actually give it, you're done, and the urge to keep going is the old audience whispering that someone's watching.
Proper is a cost, not a virtue
"Make it proper" feels like craftsmanship and is often just unbilled work for an imaginary user. The skill isn't hardening the tool against cases it will never hit; it's noticing that the hardened version is for nobody and stopping.
There's a real exception, so the advice doesn't curdle into "never maintain anything." Sometimes the personal tool quietly stops being personal. Someone else starts relying on it. It ends up in a scheduled job. It starts touching data that would hurt to lose. The moment it crosses that line, the audience comes back and the old instincts become correct again. But that's a different article, and the trick is noticing the crossing, not pre-emptively building for it.
"I'll just make it myself" as an ordinary Tuesday
The thing that creeps up on you, after a while of building this way, is a shift in what you expect from software.
For most of my life the default response to a friction was to wait. Wait for the product to add the feature. Wait for the vendor to fix the thing. Or wait for someone on the team to have a free afternoon. Software was something that arrived, from somewhere else, on someone else's schedule, and your relationship to it was mostly patience. You learned to route around the missing feature, normalise the annoyance, build the workaround in your own behaviour because building it in code was someone else's job.
That default has flipped, for me, more completely than I expected. I notice a friction now and the first thought is I'll just make the thing, not as a grand decision but as the obvious move, the way you'd grab a knife when the bread needs cutting. It is an ordinary Tuesday activity. It has stopped feeling like a project and started feeling like a chore you do and forget.
What surprises me, looking back, is how much friction I'd stopped seeing. The annoyances I eventually built tools for weren't dramatic. They were the small recurring taxes I'd paid so long I'd filed them under how things are rather than problems with solutions. The capability didn't just let me fix things faster; it changed what registered as fixable in the first place. I'll have more to say about that. The long tail of tools you'd never have filed a ticket for is its own subject.
A note for the non-programmer
If you don't write code, this is the gentlest possible place to start.
The stakes are as low as software ever gets. The only person a bug inconveniences is you. There is no production system to take down, no colleague to embarrass yourself in front of, no data that matters to anyone else. If the thing breaks, you are the entire blast radius, and you can see the damage immediately because you're the one standing in it. That is the safest sandbox there is, far safer than the small-team tool, where a confident-looking mistake can quietly reach other people.
I've written elsewhere, and at more length, about where the genuine dangers sit when non-programmers start building. They're real, and they cluster exactly where the tool stops being just for you. The audience of one is the corner of that map with the most headroom and the least exposure: build the silly, specific, only-for-you thing, point it only at your own data, and let the low stakes do the teaching.
Where the habit takes root
I keep coming back to the omelette, because the comparison holds further than it has any right to. You learned to cook for yourself before you ever cooked for anyone else. You burned things. You made the eggs too salty and ate them anyway. The low stakes are what let the skill form, because nobody was watching and nothing was riding on it.
Building for an audience of one is that kitchen. It's where the habit takes root before it ever has to be serious, where you get fluent at describing what you want, noticing when the agent built the wrong thing, stopping when it's good enough, without the cost of an audience pressing down on every choice. The forty-line script that throws a stack trace on an empty folder taught me more about directing these tools than any careful production build did, because I could be careless with it, and careless is how you learn the edges.
So build the only-for-you thing. The one no one would have funded, too specific to buy, too pointless or too embarrassing to ship, whether that's forty lines or a weekend. It's allowed now, in a way it simply wasn't three years ago, and it's the most fun and least fraught corner of the whole shift.
Final thought
Nobody asked for it. Nobody else will use it. That was never the point.
Building for an Audience of One · June 2026. A field note on personal tooling. Examples drawn from the author's own projects (Share, the Server Metrics collector, the Task API, the Amiga Juggler raytracer reconstruction, and GlyphBlaster), all built for an audience of one or very few, none of them load-bearing for anyone else.