Startup mistakes

Two years ago to this day I quit my job.

I quit for a lot of reasons but mostly to strike it out on my own and build a business. That part didn’t work out as planned; I ended up closing shop about a year later. This post is about some of the mistakes I made along the way.


I set out to build a peer-to-peer marketplace called Qhojo (pronounced ko-jo; I know, bad sign already). On Qhojo, videographers, photographers and creators could lend and borrow equipment from and to each other. Think AirBnB for camera and video gear. It took three months to build the first iteration and another three to build the second iteration. By the time we shut it down, it had about 250 signed up users and had facilitated a handful of transactions.


  1. No customer development: Customer surveying? Nah. Talking to the creative community? Nah. All that Steve Blank nonsense? Psh. That was for the b-school kids who didn’t know how to program. We didn’t follow any of that “boring” advice. Why? Because I’m an engineer and I wanted to build build build. And that mentality is exactly how you end up with (1) solutions to problems that don’t exist or (2) poor solutions to actual problems (which Qhojo was). We should have stepped away from the keyboard and talked to people.

  2. Bad name: I can’t tell you how many times people asked us “is that with a ‘c’ or ‘k’”? It was a name that was incredibly difficult to spell and more critically, impossible to reproduce after hearing. This made it tough for the casual meetup attendee or passer-by to look us up at home. For those curious, the name was inspired by the hindi word “Khojo” which means “find it”. While we lost points on spelling, we scored pretty well on meaning.

  3. High risk-to-reward ratio: The average item price on Qhojo was around $2000. Typically, rental rates for A/V equipment are about 1% of their total price so ~$20 a day in our case. Suppose an average rental span of 3 days and a commission of 10%.

    The equipment owner has to post an item, accept a request for someone to borrow that item, establish meetup logistics for the exchange, establish meetup logistics again for the return, meet the person for the return, and then verify that the equipment still works.

    Is it worth the owner’s time to perform all these tasks for ($20*3)-($20*3*.1) = $54? More importantly, is that $54 a sufficient reward for the risk of damage, internal or otherwise, of their possession?

  4. Over engineered: We focused on making the cleanest, meanest, and leanest machine out there. We automated where we could and made a moderate effort at producing maintainable code through periodic refactoring.

    This was a waste of time.

    We should have built the absolute minimum and then manually maintained transactions through the backend if need be. To hell with formality. We were in the business of proving a hypothesis yet we acted as if it had already been proven.

    There’s a broader point to be made here. Briefly, this has to do with the formal training engineers go through during schooling and professional work. In the former, engineers are taught to build efficient and elegant solutions. In the latter, code reviews check for each. Although I eventually became comfortable with a do-it-quick-and-dirty approach, I found it very difficult initially. Interestingly, I don’t see non-formally taught developers make this mistake in their startups.

  5. Lack of lender protection: We couldn’t figure out a way to subsidize the risk on behalf of the lender. We reached out to insurance brokers and insurance companies; no dice. We also talked about charging a monthly fee to members. Ultimately, we ended up putting temporary holds on the borrower’s credit card. These holds represented the entire amount of the item. This did not work because many couldn’t sustain that kind of load, albeit temporary, on their credit card.

  6. No team: I went into building Qhojo alone. One day, I posted about it on Facebook. An old friend saw it and we subsequently reconnected over beers. I asked him if he was interested in joining and he was. But he said he couldn’t commit fulltime. No problem, I thought. Any help is better than none and all the more if it’s from someone I know and trust.

    Only towards the later stages of Qhojo did I realize this arrangement wasn’t going to work out. Building a business (startup or otherwise) requires a massive amount of work and 1.5 people is not enough for it. Furthermore, when the going gets tough (and it will), you need someone there in the trenches with you. I can’t understate how important that is for one’s mental will. Knowing you’re not in it alone is a huge source of comfort on the bad days and awesome energy on the good days.

  7. Misleading encouragement: If I got a nickel everytime someone told me how great of an idea Qhojo was, I would have wised up and made my business just talking about Qhojo. Almost every creative we met burst with support when we pitched them the idea. And that was great except when we realized that while the idea is great for them, it needs to be great to us, the business, too. The analogy I’d draw here is of the person who decides to make a business out of giving money away for free. That person is going to make a lot of friends but their business isn’t going to last very long. It must be mutually beneficial.

    Looking back, I wish we listened harder to the critical viewpoints. Instead, we let the praise drown them out.

Parting thoughts

There’s a couple businesses trying to do what Qhojo couldn’t. Kitsplit, Cameralends, and ShareGrid come to mind. I really hope they succeed, but deep down, I think (3) above will prevent any from doing so.

While Qhojo didn’t work out, I’d like to think I got a very cheap MBA along the way. I’ve drawn lessons from the mistakes I’ve made above. I am a smarter person and entrepreneur for it.

edit 06/24 - additional commentary in HackerNews thread

Written on February 19, 2015