My notebook has a running page I never meant to start. It is a list of things shipping alone has taken from me. Not skills I had to learn, the list of those is boring and endless, but things I used to have and gave up the day I decided to run a product by myself. I added five entries to it over the past few months. They are not complaints. Most of them I would give up again. But I had assumed solo work was mostly an addition problem, a matter of learning more jobs, and the page is my evidence that it is at least as much a subtraction problem. Here are the five, copied out and cleaned up enough to read.
The second reader
The first thing to go was the person who reads my work before the world does. No reviewer on the pull request, no editor on the release notes, nobody who notices that the button says "Cancle." I used to think code review was about catching logic bugs. Working alone taught me that most of its value was catching the dumb, surface things a tired author cannot see in their own work, because the brain helpfully renders what you meant instead of what you typed.
I have tried to buy the function back without the person. I let a diff sit overnight before I merge it, because the version of me that reads it in the morning is a different enough reader to catch a few things. I write the reason for a change in the commit body as if I were explaining it to someone, and the act of explaining surfaces the parts that do not hold up. I lean on tests harder than I would on a team, because a test is the one reviewer that never gets bored on a Friday.
None of it fully replaces the second reader. I keep a small file of bugs that shipped because no one but me looked: a date-math error that was off by a day only in one time zone, a setting that silently did nothing for two releases. Every entry is a thing a five-minute glance would have caught. I have made peace with the fact that some of those will always get through, and that part of the cost of working alone is paid by the people who hit them first.
The roadmap
I gave up the plan I could show people. Not planning itself, but the kind with quarters on it, the kind where "search is coming in the fall" is a thing you can say and mean. A team can make that promise because the plan survives any one person's bad week. Alone, I am the only resource, and the plan does not survive my bad week, my flu, the two days I lose to a bug that turns out to be a typo. Every estimate I make is really an estimate of a single human's uninterrupted attention, which is the least reliable quantity I know.
So I stopped keeping a roadmap and started keeping a very short queue. I plan the next thing, sometimes the next two, and I refuse to dignify anything past that with a date. It feels irresponsible some days, like flying without instruments, and on the days a user asks when a feature is coming I have nothing honest to offer but "I don't know yet."
What I got back is that I mostly stopped lying, including to myself. A roadmap for one person is a forecast dressed up as a commitment, and pretending otherwise just means apologizing later. The short queue is uglier and truer. I lost the comfort of a plan and the small authority that comes with being able to announce one, and I am still not sure that trade was free.
Being good at one thing
I used to be good at one thing. Going solo, I traded depth for surface area, and now I am passable at maybe six jobs and excellent at none. I design screens a real designer would quietly fix. I write marketing copy that makes actual marketers wince. My backend works and would not impress anyone who does backends for a living. Every part of the product carries the faint fingerprint of an amateur, because every part of it was made by someone doing that job part-time.
For a while I treated this as a problem to fix, as if I could read enough about typography between releases and come out a designer. I cannot. The honest move was to accept the ceiling and decide where to spend my few hours of real focus. I let most things be a competent five out of ten and pour the effort into the one or two places where the product actually has to be sharp, which for me is the speed of the core action, the thing the whole app is about.
The strange gift is that nothing gets lost in a handoff, because there is no handoff. The person who designs the screen is the person who writes the code behind it and answers the support email when it confuses someone. The seams between jobs, where teams leak the most, simply are not there. I gave up being good at one thing and got a blurry, end-to-end view of the whole that I do not think a specialist ever quite sees.
Someone else on call
There is no one else on call. When something breaks at one in the morning, the rotation is me, and after me it is nobody. The first time my send pipeline started failing silently (a server hiccup that left notes stuck instead of delivered), I found out because I happened to be the user who noticed, and I fixed it at an hour no employer could have asked anyone to work.
The lesson was not "work more hours." It was that I had to engineer the absence of a team into the product itself. If no human is on call, the software has to fail safe on its own. So the send path became an offline-first Outbox: a note is written to durable local storage the instant you hit send, and a background worker keeps retrying delivery with backoff until it succeeds, whether that is now, after a reboot, or after the subway. I built it less for the user's convenience than for my own sleep. The resilience I could not provide as a person, I had to provide as code.
I gave up the safety net of someone else handling it, and the cost is that these days I over-engineer for failure in a way a bigger team might call paranoid. Maybe it is. But when you are the entire on-call rotation, the cheapest incident is the one that quietly resolves itself while you sleep, and I will spend real effort to buy more of those.
The person who tells me I'm wrong
The last entry is the one I underestimated most. I gave up the colleague who tells me I am wrong before the market does. Alone, every idea I have is reviewed by a board consisting entirely of me, and that board approves almost everything, because my bad ideas show up wearing the same confidence as my good ones. There is no one in the room to say "that is a feature for you, not for users," which is the single most useful sentence I have ever been handed and now have to remember to say to myself.
I have cobbled together substitutes. I keep a decision journal where I am required to write the strongest case against what I am about to do, and writing it honestly kills a fair number of plans. I ship small and fast so reality gets to disagree with me early, while a mistake is still cheap. And I have started treating the comment section as a de-facto review board. When I wrote here recently that capture latency is the only note metric that matters, a reader who builds a writing tool replied with the same finding from his own product: he had a category prompt blocking the start of a draft, removed it, and watched people actually start writing. That time the board agreed with me. But agreement from a stranger who tested the idea independently is worth more than agreement from the board inside my own head, precisely because it could have gone the other way.
That is the one I would warn a new solo dev about. You can replace the reviewer and the on-call engineer with discipline and code. Replacing the person who disagrees with you is harder, because the failure mode is invisible from the inside. You do not feel an echo chamber. You just feel correct.
What is still on the page
The list in my notebook is not finished, and I have a feeling it never will be. Subtraction keeps showing up where I expected addition. I will copy out the next batch once it is long enough to be worth reading.
If you ship alone too, tell me the entry you would add: the specific thing you gave up that you did not expect to miss, and whether you bought it back somehow (with a habit, a tool, a piece of code) or just learned to live without it. I am collecting these now, and the ones that still sting are the useful ones.
I'm a solo developer. Simple Memo is the iOS app I make by myself: you type a line and it lands in your email about a second later. I write here every few days, mostly about the parts of going it alone I had to learn the slow way.
Top comments (0)