← The Journal
Craft

What a one-person studio can actually do

By Mark3 min read
A luthier working alone on a guitar body at his workshop bench
Photo, Andrea Piacquadio / Pexels

Not a claim that small is better at everything, because it isn't. A straight look at what a studio this size can do that a large one structurally can't, and what it gives up for it.

There's a version of this argument that's just flattery for small companies, and I'm not interested in writing it. Plenty of things need a large team and won't get built well by one person. If you want a product with 24-hour support in nine languages, I'm the wrong shop and so is every shop like mine.

What I do think is true is narrower. A few things are available to a studio this size that aren't available to a big one, and none of them are about talent. They're structural.

Nobody's quarter depends on shipping it

The strongest thing about working alone is the ability to not ship.

When Catchlight's editor had a bug where the caret slid under the keyboard, the honest fix was to rewrite two screens in a different UI framework. Months, to arrive at screens that look exactly like the ones already there. No product manager on earth signs that off in a company with a runway, and they'd be right not to, because the sensible move with a team and a deadline is to patch around it and move on to something a customer can see.

I could take the months because the only person whose plan got wrecked was me. That's not virtue. It's just that there was nothing structural forcing the other decision.

The whole thing fits in one head

A guitar maker working alone doesn't hold a meeting about whether the neck angle suits the bracing. They already know, because they cut both.

Software gets its worst seams where two teams meet. The sync layer written by one group and the editor written by another agree on an interface, and every gap between what each assumed shows up later as a bug that nobody owns. I've spent years of my working life on exactly those bugs.

When one person builds the storage, the encryption and the screen the text lands on, the seams aren't negotiated. That doesn't make the code better, and I'd be lying if I said mine has no bad corners. It means the failures are mine, in one place, and findable.

The business model doesn't need dark patterns

This one is almost boring and it's probably the most important.

Dark patterns aren't usually the work of bad people. They turn up when a number has to go up by a date, and the honest ways of moving it are slower than the dishonest ones. Add a growth target and someone will eventually propose the notification that isn't quite necessary, or the export that's just difficult enough that you don't bother.

I don't have that number. One honest price for a complete product, or free and open where that works better. It isn't discipline on my part, there's nothing to be disciplined about.

What it costs

Speed, obviously. Everything takes longer and there are features people want that I haven't got to.

Bus factor is the real one, and it's worth being blunt. If I stop, nobody picks it up. My answer is that everything is open source and every product exports to plain files you can read without my software, so what you'd be left with is your data in an open format and a codebase somebody could carry on. It's not the same as a company that outlives me. It's the best answer available to a studio of one, and anybody telling you otherwise is selling something.

You also lose the fresh pair of eyes. Working alone means being wrong for longer, because nobody in the next chair says that looks off. I've been wrong about the same bug three times in a row before instrumenting it properly and finding out the platform simply doesn't do the thing I assumed.

The trade is worth it for the sort of product that gets ruined by growth pressure, which is most software that holds anything private. It isn't worth it for a lot of other things, and I'd rather say so than pretend the small shop wins every argument.