The One-Person Studio Playbook: 15 Products In, Here Is What Actually Works

I keep a list of products I have shipped. This week the list hit fifteen. Some have users. Some survive mainly on dependency bumps. One or two quietly load-bear for people I have never met. One person built all of them on nights and weekends.

I do not have a magic formula. I have a set of tradeoffs that stopped working for me, and a set that did. This is the honest version of a playbook I wish I had read three years ago.

The bottleneck is not what you think

When I started, I assumed the bottleneck was execution speed. Write faster code, ship faster, launch faster, win. Three years in I can confirm this model is almost entirely wrong.

The real bottleneck, in order:

1. Which thing to build next. This is the decision that eats the most weekends and the one most people solve worst.
2. Whether to keep going when the thing is 60 percent done. Most solo projects die here.
3. Who you tell about it once it ships. Nothing is more wasted than a shipped product no one sees.
4. Actual engineering. A rounding error compared to the above.

If your mental model puts engineering at the top, you are optimizing the wrong loop.

The backlog is the product

I run one ideas file. A plain markdown document, chronological, no tags, no priority column, no tool. When I have an idea I write the idea down. When I look at the file on a Saturday morning, the ideas that have been sitting for two months and still make me want to open my editor are the ones worth building. Everything else quietly dies of indifference, which is how ideas should die.

The tools industry tries to sell you a better way to manage ideas. A better way does not exist. Only the discipline of writing the idea down and letting time filter it.

The first rule of scope: if it still seems fun at mile one, the scope is too big

Every solo project has a mile one. You sketch the README. You pick a stack. You imagine the demo. That phase feels fun because you have not hit anything hard yet. If the project still looks exciting at mile one, the scope has almost certainly overshot.

The things I have actually shipped were the ones that looked boring at mile one. A URL shortener with a decent admin panel. A brand-icons npm package. A content filter for a narrow list of languages. None made me excited to start. Every one shipped because the scope was small enough to fit inside a single weekend of focused work, with a second weekend for polish and a third for launch.

The things I abandoned were the exciting ones. A multiplayer collaborative graph editor. An open-source Substack clone. A fully self-hosted analytics stack. Each of them felt great at mile one and died by mile three.

Ship the smallest self-contained thing first

Most solo founders lose because they optimize for the right endgame and miss the nearest finish line. I now default to shipping the smallest thing that is useful to someone, even if that thing is embarrassingly narrow.

Glin-Profanity started as a single-language JavaScript filter with one regex file. That version shipped in three days, got about 20 downloads in the first week, and taught me enough about what people actually wanted that the next six releases built on real signal, not hypothetical. If I had waited until the 24-language version to publish, the library would never have shipped.

Same pattern with theSVG. Version one was 400 icons, shipped as an npm package with no docs site and no variant support. People installed it anyway. They asked for variants. I added variants. They asked for more icons. I added more icons. Three years later the library has 5,650 icons and a live site. None of that existed in version one. Version one was the point.

The launch is work, the launch is not optional

The hardest lesson I keep relearning is that shipping is half the job. A solo founder who writes code and does not write about the code has built a good tree and has forgotten the forest.

Every product I have shipped has a launch checklist. A boring list: the Dev.to post, the Hacker News submission timed for when someone might see it, the X thread, the email to the three specific people who care about this kind of thing, and the follow-up post two weeks later with the "what actually happened" numbers. Skipping any item halves the reach. Skipping two items launches your project into a closet.

The one I skip most often is the two-week follow-up. That one matters most, because people remember projects with a second beat more than projects with only a flashy first beat.

Maintenance is the tax you pay for credibility

Fifteen products in, I spend at least one weekend a month on pure maintenance. Dependency bumps, security patches, small bug fixes, release notes. None of this work is fun. Every bit of it keeps the stars from turning into complaints.

The trap: treating maintenance as optional and building as the real work. The reality runs the other direction. A product with six months of stale issues signals to every future user that you gave up. A product with quarterly release notes and fresh tags signals you are still around. Both signals compound over years. Compounding is the game.

I now schedule maintenance like a meeting. First Saturday of every month, 10am to 2pm, one project at a time, rotating through the list. The weeks I have skipped this block are the weeks I have later regretted.

The emotional load is the real one

The part that nobody writes about is the emotional load. Fifteen products mean fifteen sets of issues, fifteen sets of feature requests, fifteen sets of users who think their use case is the most important one in the backlog. Each one is legitimate. Collectively they are crushing.

What I have learned to do:

• Reply to every issue once. Even if the reply is "thanks, I will not get to this for a while." People forgive slow. They do not forgive silence.
• Close issues aggressively. An open issue you will not fix is a pending emotional tax. Closing it with "not planned, here is why" kindness to both sides.
• Do not read feature requests on Monday. The week ahead feels harder when the inbox opens with demands. I read requests on Saturdays when I have the energy to actually do something about them.

The advice I stopped giving

When someone asks me how I ship so much, I used to say "wake up early, work in blocks, do not watch TV." I have stopped saying this. None of that explains why I actually ship.

I ship because I have given myself permission to work on whatever makes me feel alive that week, and I have enough shipping-momentum from past projects that each new one skips the "will this work" anxiety. The question becomes "how long until the first user shows up."

Momentum is the thing nobody sells you. You can only earn it by finishing things. Finishing is the skill. Finishing is the whole playbook.

What I would tell myself three years ago

• Do not try to build the big thing. Build the small thing next to the big thing.
• The first version should embarrass you on at least one axis. If it does not, you over-scoped.
• Launches are work. Schedule them. Do not trust yourself to do them if they are not on the calendar.
• Reply to every issue once, even if badly.
• Close the project that has not moved in 60 days. Free the weekend for the next one.

Fifteen products in, this is what works. Ask me again in another fifteen.