Beautiful Documentation Made Easy

Would you recommend this product?
No reviews yet
Hey all, founder here! I've worked at a bunch of startups, and inevitably we'd have to make a and I'd wonder why we were re-inventing the wheel each time. Every startup needs this, they all have the same basic features, yet every startup has to do it themselves. Ergo, ReadMe! It's more than just documentation; it's a full developer hub for your community. The goal is to make it so any startup can have beautiful, interactive, collaborative, Stripe-quality docs without wasting valuable time that should be spent making their core product even more awesome!
Upvote (26)Share
@gkoberger beautifully done. Funny you say "Stripe-quality" because that was the first thing I saw when I checked out the 3-col example as well. Granted I don't know if Stripe was the first to implement that style API documentation, it seems they've owned the look. Personally the last time I planned a round of dev docs I considered building that same style as well, but didn't want it to look the same and feel like a copy. Curious how others feel about API documentation styles and if we should have a standard like this. I do really like the integrated tester, that's a big win. Not sure if it's intended but the try feature on your first example produces a 404.
@noinput Thanks for the feedback! I begrudgingly added the Stripe-style docs; it was the #1 requested feature. Which is understandable; they do look great. I've slowly started to really like them, too. I would love to eventually take a step back, though, and see if I can come up with a new, unique style. The examples are all *really* bad. That was my plan for today, to flesh them out. Then I ended up on PH by mistake :) I'll fix them ASAP!
@gkoberger Really excited about this service. We use GitHub wiki extensively, but it's always been the least loved of their features (seemingly). Wonder what kind of pricing experiments you guys did before settling at these price points.
@abhic Good question. We spent a ton of time talking about and reworking the pricing. We really wanted a free tier. I believe beautiful, easy to maintain documentation should be free for every developer. As for the paid, we looked at it from the perspective of how long it would take a developer to create a basic developer hub (let alone one with all the features ReadMe has). We talked with a bunch of companies (many of whom had a full-time engineer or two working on the developer hub), and picked $99 for a reason. We started with the assumption that the average SF engineer costs a company approximately $200k/year, which works out to be $100/hr if he works 40 hours a week and gets two weeks off. So, that's where $99 came from (although it's currently $39.50 for PH users!). We're insanely confident we can save any company *at least* one hour a month in engineering time – although weeks saved is a much more accurate unit of measurement :) As fas as how we compare? Mashery costs $9k/month, and Apigee is pretty close. GetSatisfaction is $1k+/month, ZenDesk adds up quick, too. All of these offer features ReadMe does not, however we think our features are perfectly tailored to most startups' needs.
@gkoberger This is a really interesting case study in Pricing. You have laid out some broad issues in here - product, research, competition, value proposition and customer benefits. Will do my best to digest it all :) So, we have done a bunch of testing in a similar space - everything from $-1 (we pay the end user) to $0 to $1 to $10 - $500. We have full time users (developers) for your product (Readme), but we certainly don't cost them on our balance sheet the same way a pre-revenue SF Co might. We use GitHub a lot & now with GDrive getting better with their plugins, our requirements are met. We kinda sorta use ZenDesk, thanks to their 'Startup' plan. For a service such as yours, where there is going to be entrenchment (lock-in) over time, I think the only thing I would care about is to identify the cohorts in the first few quarters - will never pay - will pay X > 0 for beta - will pay $MarketValue for post-beta My focus would be to keep track of every single relationship with every single user. Then I will be able to experiment my way up the 'engagement ladder' with them. - will never pay -- what material benefits are possible --- product testing (great products take time) --- referrals --- $1 - will pay X > 0 for beta -- what features will they pay more for from the current roadmap These two cohorts are the most interesting to me. In our service, we discovered that the - will never pay cohort will pay us $10 for a one-time fee to unlock key features in our app (think in-app upgrades) but balk at any mention of 'monthly' charges on their credit cards. Seeing that you guys just came out of the gates, this pricing surprised me. But your reasoning was interesting. Maybe you guys are chasing different proof-points than I assume you might be in this phase of your startup. Will be following your progress :) Best of luck with your next milestones. (Whoa! this was a long ass reply...sorry bud.)
You're a baller, @gkoberger: Glasshole Kitty and Glasshole Owl could be friends. Congrats on the launch. :)
Upvote (13)Share
@rrhoover I can't imagine how much I've annoyed you over the past 6 months with my "I'm totally launching next week!"s :)
@gkoberger "If you're not embarrassed at launch..." ;)
@rrhoover oh I'm embarrassed still :)
@rrhoover been trying to convince @gkoberger of this for weeks, months, years ;)
It's like bootstrap for documentation. Pretty nifty. a++
@jedgar Thanks John! We're using you guys for all our tasks that require heavy lifting (syncing, git stuff, etc) :)
This just launched publicly out beta last week and looks awesome; with some great examples at the bottom of the page.
So this is a "phileas & fogg" product.. meaning you built this on a Costa Rica getaway/hackathon in 80 days, right? This is an extremely interesting way to launch a product! What was that experience like? I'll be trying out your product too, I think something like this will definitely save me a lot of time.
@acoyfellow yup, the MVP was built in Costa Rica. I've been meaning to write a blog post... but basically, it was awesome. We got to travel and explore a new country, with almost none of the distractions you'd have in SF. Highly recommend anyone looking to start a company consider doing it in a foreign country; one of the best experiences of my life.