I Hated Writing Documentation so I Founded a Company

People tell you to start a company around doing what you love. I founded a company to stop doing what I hated—documentation.

I started my career as a developer at Mozilla working with PHP, before rising through the ranks to Python. After I decided to leave Mozilla, I did a lot of freelance development work for startups, big businesses, and even VCs.

And whether I was working for a company like Mozilla, or I was working with a solo developer on an app, I always found myself knee-deep in terrible documentation. While most developers didn't give this inconvenience much thought, it drove me insane, and I needed to do something about it.

Fast forward five years, and here I am at my own documentation-made-easy startup, ReadMe. Yet whenever I tell people about my business, I still always hear: “Wow, you must loooove documentation.” Not at all. Here's how I turned my biggest gripe into a business.

The Gripes of a Backend Developer

Y Combinator co-founder Paul Graham points out that a lot of startups are born because of schlep blindness. Basically, most people accept “schleps”—tedious tasks like filing or processing payments—as necessary evils. The inconvenience fades into the background and the problem gets ignored. If you can identify a big enough problem that everyone else overlooks, you've got a great starting point for a company.

Terrible documentation was my “schlep.”

I've felt like API documentation was super important for a product's success—even back in 2010. APIs opened up what you built to the rest of the software ecosystem. It let other developers plug in your product into whatever they were working on. And the more people who rely on your API to build their own software, the more indispensable your product.

Good documentation meant the difference between other people using your API or ignoring it completely, but most people treated it as an afterthought. There was no industry standard for the best way to document, so everywhere you turned you'd find different half-hearted attempts at it.

Documentation was often:

• Out-of-date. Developers would throw together a slapdash docs.theirstartup.com page and never touch it again. As a result you'd get cryptic documentation that you'd have to sift through to find the relevant bits, and then try and figure out how to make sense of those.
• Incomplete explanations. Developers who read API documentation come from different coding backgrounds with different levels of experience. What comes across as obvious to the maker isn't at all obvious to most consumers.
• Disorganized. Those developers that did put a lot of time and thought into their documentation often came up with an overwhelming online manual. As a user, you wouldn't know where to start, and figuring out the relevant information for your use-case was near impossible. So even a valiant effort at documentation often falls short of its ultimate goal.

But you could hardly blame the makers. The task of documenting your API and explaining every single use for it was a huge undertaking, since good documentation takes months or even years to build out. On one hand, the utility of a API was obvious and great documentation seemed necessary, on the other, the task of crafting great documentation was too labor-intensive.

In my first few years as a developer, I had found the schlep that would inspire me to one day build my own product.

How to get rejected from YC

DocHub was my first attempt to fix documentation. It was essentially a template for documentation that included a nav bar, versioning, and places for users to comment. And even though it was enough to land me and my friend Matt Garner an interview at Y Combinator, it wasn't enough to seal the deal.

Most people apply to YC with a company and a business model. They typically have a product with some traction, and an inkling of what to do with it. All we had was an idea, a terrible name, and slogan: “Writing good documentation is hard. But it doesn't have to be. Really!” But when we landed the interview, it was my first sign of public validation. Landing the interview with YC was a significant sign that people might care about what we were making.

The VCs didn't even let us finish our pitch. They interrupted saying that what we were offering was a consulting service, not a product. In VC speak, that means we didn't have an idea that could scale. We floundered through the rest of the demo, even though the die had been cast. Within a few weeks we received our rejection letter.

The thing with a schlep is that the problem that seems so obvious to you isn't obvious to other people. Our failure to get into Y Combinator wasn't because we had a bad idea. It would just take much more than a week-old prototype to get people to see past their schlep blindness.

A Market for ReadMe

The market wasn't right for my tool when I was first rejected from YC, but two years later everything had changed.

The rise of API-first companies proved how valuable an API is to other businesses. Apps could now build call functionality via Twilio or credit card processing functionality via Stripe quickly and easily. And because these companies didn't have a consumer-facing side, good documentation took the precedence. Crystal-clear documentation was what allowed everyone from lone developers to multi-million dollar companies to be able to use them.

These API first companies essentially created a market for a product like the one I had been trying to build for almost five years. So now that I had better developer chops, a sense of the market, and unshakable conviction in my idea, I finally built ReadMe. Here's what I came up with for my the first version:

• A custom domain. So that developers didn't have to start their docs from scratch.
• HTML/CSS pre-built layout. Developers could type markdown within the layout, and add in different types of modules for things like code snippets, or warnings. They could focus on the content, and not the web design.
• API explorer. A tool that let users sandbox their calls from the documentation to get an idea of how the API works.
• API key generator. A tool that saves developers the trouble of having to sift through the documentation to learn how to get their key.

It was a platform that equipped developers with tools that saved the makers a lot of explaining, and saved users a lot of searching and navigating. And I didn't have to prove that this was useful to anyone anymore. All I would have to say was Stripe-like documentation, and people immediately recognized the value in ReadMe.

ProductHunt posted our page up months before we had planned on launching. A week later we launched on Hacker News. And between these two, we got over 5,000 signups and became profitable. Oh, and the second time we applied to YC—this time with a real product and some big customers—we got in.