ReadMe and Launching Early
The story of ReadMe, as told by its founder, Gregory Koberger. #
I originally had the idea at the first startup I worked at a long time ago. I had to document their API and a few JS widgets for developers to consume — and it seemed pretty crazy that there wasn’t a simple way to build a developer portal. The concept of which is pretty standardized, yet everyone was spending time building their own, essentially wasting the most precious resource of all, developer time.
I’ve always had an interest in building tools for developers because I believe that usability in software development is sorely lacking. I kept coming back to this problem.
Over the past few years we’ve seen some great examples of companies focus on documentation, and I think it’s great: the faster people learn, understand, and build, the more value is created.
There wasn’t a particular point at which I deliberately sat down and said I was going to build ReadMe and make it a company. It just so happened that whenever I tried to work on some other product, I would build out elaborate developer hubs with APIs tidier than the actual product.
I simply found myself building (what became) ReadMe, and it just became clear that working on anything else would be silly — I had to see it through.
Whenever you tell someone what you’re working on, they invariably say things like that’s cool, or maybe go as far as saying they would use it.
In our case, every developer I talked to had war stories of an API they couldn’t figure out or a code library they should have documented better — they asked specific questions, and shared their bottlenecks and roadblocks.
I never found myself having to convince anyone that this was a problem.
As I went along building ReadMe, I did some freelancing on the side. I wish I had done a bit less freelancing, and made the jump into full-time earlier.
I remember being on the Product Hunt podcast in January of 2014, and saying that we were going to launch in about two weeks. However, I kept finding more things that I believed were needed prior to launch. Every time we’d narrow the gap, I would add more features or polishing something further.
8 months later, we still hadn’t launched…until…
I got a text message just as I was about to go to bed on a Sunday night: “You’ve been posted on Product Hunt!”
I freaked out and texted Ryan Hoover (the Product Hunt founder) asking him to take it down, and did whatever I could to get it removed. But it was too late; the post started getting upvotes, and I realized that this was it: my procrastination was over, and we were launching.
My list of “MUST DO BEFORE LAUNCH” stuff melted away, and it turned out there were really only 4–5 things I desperately needed to do. So I poured myself some coffee, and by the time the sun rose over the West Coast, we were completely ready to go.
We ended up being the fifth post of all time on Product Hunt and started generating revenue overnight. I’m glad I took the time to polish the product, but… I’m even more glad someone made that post. The product would probably still be in development if they hadn’t!
Y Combinator #
The success of the Product Hunt launch gave us much needed traction, and that’s the most important thing when raising money or doing pretty much anything, from hiring to sales. We had just enough success to use as momentum to keep things going. So YC felt like a natural next step. I had actually applied to YC two years prior with a similar idea called LiveDocs—for anyone thinking of applying that has been rejected previously, I encourage you to try again!
At the time, we had no customers nor a product, it was just an idea. We obviously didn’t get in, and I stopped working on it right after because I was rather disappointed and wasn’t really committed.
This time around, it didn’t matter as much. Even if we didn’t get into YC, I was still definitely going to work on it. It was more than just a good idea — we had customers, money and most importantly, knew it was working.
I decided that if I didn’t get into YC, I would try to bootstrap it. And do I love the idea of bootstrapping; the only problem is that you’re not able to move as fast.
Plus, VCs give you a lot more than money: they give you advice, introductions, a stamp of approval, and much more. For example, early on, a lot of big companies were uncertain whether our product was a good fit for them. Having big name VCs backing us went a long way in convincing them to choose us.
After we launched ReadMe in September, we applied to YC a month later. Luckily enough, we got in, interviewed in November and then had our first meeting in December. The months after we launched moved really, really fast.
The Future #
When I started ReadMe, the most I had ever really though about was “kinda like WordPress, but for documentation” — which is what we currently do.
Yet as I saw how people were using it and learned the space better, I started to see the impact we could have. APIs are a huge business — they empower businesses to work together and people to build powerful tools.
Documentation is the UI for APIs and code libraries, which leaves much that can be done under the surface. Google predicts 3 billion dollars a year will be spent on API management by 2020, and we have a platform that everyone is already using for documentation.
Let’s look at a slightly different market: CDNs and website management. There were a ton of gigantic players in the space, charging a lot of money to big companies. Then, Cloudflare came along, and made it dead simple to just flip a switch and get awesome new features.
Finding ways to make APIs easier to write and consume — so far we’ve primarily been working with public external APIs. And microservices (essentially internal APIs) are becoming huge right now, which is something we haven’t fully explored yet.
One thing I noticed was things never moved as fast as I expected them to. Two years into the future seemed like forever, yet the past two years have flown past. Everything moves much slower when you have to hire, deal with customers, deal with random things breaking, and so on.
Feature Creep #
I did one thing that really hurt us, I made a deal with a larger company for some custom features. As time passed, they only wanted more and more, until I finally said enough.
They begged us to reconsider and I relented after about an hour. Four months later, the feature creep was getting out of control.
Big companies are horrible to work with early on. It took all our resources for months, and almost killed us. And in the end, it didn’t even work out.