@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 ;)

@tommoor Thanks Tom! We're currently using APIDoc (apidocjs.com), since it felt the most right to me: inline comments, every explicit, matched how ReadMe works. However, the eventual goal is to have convertors for Swagger,etc. As for community – honestly, probably because all of them just launched within the past week (along with ReadMe). Brick, for example, was hosted as a GitHub page until last week. That's not much time for people to start asking questions. You may still be right, I guess we'll see :) That being said, the "Suggest Edits" feature has been getting *a lot* of usage. If nothing else, people love the community aspect in that regard. See you again at the next PH brunch!

@gkoberger the suggest edits feature seems an awesome addition

@gkoberger cool stuff, I hope the community section does get used for questions as it would add a lot of value to the product! Seriously considering implementing for our docs. :-)

@tommoor dooooo it :)

@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.

@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.)

@dskaletsky Thanks for being an awesome beta tester, Derek!

@dskaletsky api.knowtify.io is a dead link for me

@_jacksmith Exactly! Thanks to Readme.io! I'm sure @gkoberger would love that answer, but the reality is I was mistaken earlier. We had our documentation at knowtify.io/api :)) It's still live, but we haven't updated it in a long time - all updates are on http://knowtify.readme.io/

@dskaletsky I can confirm that the readmeio api version looks a lot better!

@jessepollak totally going to add your testimonial ASAP :) didn't forget!

@alirussell Great question! If you want to prototype and test APIs, apiary is perfect. It even has good public facing way to browse APIs. However, the ability to document an API is more of a side effect of their core product. Your page is branded with Apiary in the top left, and there's not really a focus on topical guides or tutorials. It's focused on API end points, which is similar to handing someone a dictionary and saying "learn English". Lastly, readme has a huge focus on community. Support snd comments, plus the ability for anyone in the community to suggest edits. This helps keep your docs up to date. Apiary is great for certain use cases, but the target markets are significantly different.

@orarbel music to my ears :)

@nzieber I wouldn't have it any other way :)

@jedgar Thanks John! We're using you guys for all our tasks that require heavy lifting (syncing, git stuff, etc) :)

@samuelbeek Yup, something like that is the next step. Here's my rough roadmap: * Version 1: individual developer hubs, which will hopefully get lots of users and APIs in the system. * Version 2: start doing things like app management (i.e. a dashboard where your users can create/delete/etc apps and manage keys) * Version 3: everyone's developer keys and APIs will be in one location, so we can start doing cool stuff to make everyone's lives easier. (But don't worry, the developer hubs are here to stay! I don't believe APIs belong on a GitHub-esque central location; they're too core to a company's brand.) That being said, a more short-term option would be for ReadMe to generate Dash-compatible docs. I'll add that on the roadmap, too!

@gkoberger I understand your roadmap. Adding something like dash-export would be amazing! Keep up the great work: it looks very slick:) from what I've seen so far.