My favorite speaker at YCombinator was Kevin Hale, the founder of Wufoo. He taught me that everybody in a company should be doing personalized support so that you can identify (and fix) the most painful user experiences. He called this “support driven design” and emphasized how important it was to his company’s success. He also showed off the internal support tools he built. I thought they were amazing: no canned replies, customer information directly inside Gmail and common actions at your fingertips.

Wufoo’s Support Toolbox

That was almost two years ago.Since then, I’ve used dozens of tools to handle support for Minefold, a company I founded with Dave Newman to make simple game servers. As our service grew to nearly 80,000 players, we discarded tool after tool, frustrated with difficult interfaces, terrible email integration and limited APIs. Each tool ignored crucial parts of Kevin’s vision of support-driven design. I didn’t want to build a competing product, I just wanted to improve the software I already used.

This isn’t an uncommon feeling for a software developer. After using and contributing to open-source libraries, I have high expectations: I find myself itching to fork the projects I use every day. Imagine all the little tweaks I could make to help software suck less. Then how amazing would it be if everybody could help out too! Dave told me that he would have loved to help Amazon AWS add CORS support to S3. Matt (a friend from YC) described how he would fork Mixpanel’s funnels.

My need to fork everything became infectious.

I started dreaming about a world where I had the opportunity to change every product I touched. In this world there would be three core principles: