Daniel D. Beck

How small is too small to launch new docs?

When you’re writing documentation or other content that can be published on your schedule — “when it’s ready” — then it can be hard to know when you’ve done enough to launch. If shipping is not tied to an external deadline, such as a product release, a conference, or other fixed event, then it’s on you and your content alone to make the decision. How much is enough?

The risks and rewards of launching big

Launching small feels wrong. I share in any reluctance you might feel about it (even publishing an essay like this makes me anxious). Launching small feels like cheating, since you know you could always write just a little bit more. Even if your audience doesn’t notice the gaps, you’re intentionally leaving some users’ needs unmet, which feels unfair.

By comparison, launching big is attractive. The big launch is a notable event that you and your coworkers get to talk about. To say that you launched a site with dozens of topics is a more impressive bullet point on your resume than it is to say that you grew the same volume of content over time. It’s motivating to do the heroic deed of helping all your users at once (however true that is in practice). What’s not to like about the big launch?

The truth is that bigness itself is a source of failure. Large text corpora on the Web have failure modes that don’t have much significance to small sites. Fundamentally, each additional topic complicates a site. With every added topic, your users’ task of finding relevant content is that much harder (to say nothing of the content that exists outside of your control).

For example, poor navigation is devastating to users when you’re offering lots and lots of topics, while a small number of topics requires very little navigation to begin with. Likewise, consider search: if you have many pages, then some sort of search becomes mandatory. Whether you’re deploying your own or relying on external search engines, search can break, sometimes spectacularly.

Sooner smart with smaller sites

Small sites fail too, of course, but the repairs are easier to make. Fewer pages, fewer topics, and fewer words require less revision and maintenance. A small site has fewer technological points of failure (which is particularly valuable in the early days, before you’ve developed the working knowledge needed to fix stuff).

Perhaps most importantly, the smaller you start, the more opportunities you get to refine what it is you’re building. The feedback loop is tighter: you ship, get feedback, and iterate on a shorter time scale. The longer you wait, the longer you go without learning from your audience. Your very idea of what is “enough” to launch can be refined over time, like every other facet of your content.

Instead of launching big, consider launching extremely small. I’m not even suggesting shipping new content when it’s merely minimal. I’m suggesting that you ship content that’s in a state of actual unreadiness. Single-serving sites are the absurd proof of concept. If a site had almost but not quite zero information, would it still be useful? Implausibly How Many People Are In Space Right Now? or Down for Everyone or Just Me persist at being useful. Your new content is probably more substantial than that, no matter what state it’s in.

Do you have one page that you can publish? That’s enough.