Jedi build their own lightsabers

I was down at Stanford recently with Adam, and sat in on one of the classes he’s taking there. Later on, I looked around at some of the resources Stanford makes available on the web. They provide a lot of fantastic material for free. One thing I found was this video series of Larry Page and Eric Schmidt from Google, speaking at Stanford in 2002. I’d highly recommend it for entrepreneurs. (Each video is a few minutes long, and the whole set is about an hour.)

Larry’s segment on tips for entrepreneurs, for instance, is fantastic. As he says, the advice is counter to a lot of what you’d hear as “standard wisdom” about technology startups. His point about the value of solving hard problems is one of the most difficult things for me to get through to people who take my Entrepreneuring for Geeks tutorial. A lot of investors and advisors will tell entrepreneurs to do the least amount of work possible, so that they can get going quickly. You can get going more quickly this way, but then you’re stuck trying to build a real business, instead of just a thin UI on top of someone else’s business. If you’re making all your money off of AdSense (and you’re not Google!), who really owns the relationship with your customers? Most people don’t think this way, and they should.

Joel Spolsky has a great article on this called, “In Defense of Not-Invented-Here Syndrome.” He talks about the Excel team making their own compiler and the benefits they got from that. He proposes a great test for making decisions like this:

If it’s a core business function — do it yourself, no matter what.

I’ve always referred to this idea, geekily, as, “Jedi build their own lightsabers.” If you’re going to depend on your lightsaber as your principal tool and weapon, you’d better know that it works.

We faced this decision at Wesabe when it came to syncing data from banks and credit cards. There are a couple of existing businesses that will do that for you, but when we looked at them, we realized that there were huge problems with going that route. First, we’d have to completely give up any control over our users’ privacy, since those companies would need to hold all of our users’ bank and credit card passwords, and they insisted on keeping a full copy of our users’ transaction data. That wasn’t compatible with our Data Bill of Rights, which we hear positive responses to every day on our support line. Having control ourselves leads directly to being able to provide control to our users, and that’s what our users want. Second, syncing transaction data is central to our business. Let’s say that we started to become successful — if we had a single-source provider for that data, that would mean they would have full price control over us, and would get the full benefit of any value we created. It would be like installing a black hole at the bottom of our own bank account. Finally, we would have to pass that cost onto our users in one form or another — either by charging them a high price, as some of our competitors do, or by selling their data to advertisers and marketers, which would completely corrupt our vision, to help people get control of their money.

So, we built our own transaction syncing infrastructure, and we did it our own way. We can provide those services to our users for free (in both senses — for no money, and with freedom to control their own data), and with much higher privacy protection — by giving people a client program that keeps their bank username and password on their own computer. Since we started with that as the first option, we now can extend to other syncing formats, including ones that are more convenient than installing a client download. People who took the easy route will be left with only one option for how to sync data, while we will have greater range of motion.

As Larry says, this isn’t the common perspective, and others will surely disagree in the comments. But hearing Larry and Eric speak about this is great, and if you’re interested in building a business, I think their talk is a fantastic resource.

tags: