Incorporation etc.

Wow, I seem pretty full of myself in the last post. I stand by the general sentiment, though if I were to rewrite it, I would probably use fewer literary metaphors. And I think that at this time I basically have made my decision - I'm leaving as soon as the lawyer comes through with incorporation and IP release.

Speaking of lawyers, we met with Sam Mawn-Mahlau of Edwards Angells Palmer & Dodge on Monday. He's the same guy who litigated the Ars Digita custody battle for Phil Greenspun. It was basically a massive infodump that left my head hurting for hours afterwards - I had tons of questions, and he brought up tons of issues we hadn't even thought of. For anyone thinking of starting a company, I'd recommend meeting with a good lawyer (with experience in the particular area of business you're in) as soon as you're sure it's something you really want to do. It can be really expensive (we're expecting a bill of about $4K for this incorporation and releases) but it's generally more expensive not to take care of it.

I've been prototyping the game-creation engine this whole time. As I think I've mentioned in previous posts, we have the conversion-to-flash stuff all prototyped-out by Mike, and I got it to build on Linux. We also have a pretty decent translation to JavaScript, so you can pretty much play it using DHTML only. The next step is to get the actual customization going, which has presented some pretty thorny interaction-design issues. We want it to update the game behavior & appearance in real-time, which a.) means lots of observers and b.) means we need to specify and customize a lot of properties that don't have obvious visual representations. Without getting into scripting languages, how do you specify "When the user presses space, create a new PlayerBullet at the location of Player", for example, or let them add different bullet types?

Now I'm looking at the YUI widget set and trying to do a few prototypes with it. I want to avoid having to write all my own widgets from scratch, as there are a lot of little gotchas with JavaScript that can cause little bugs.

To really live, you must be willing to die

"You are the true master of death, because the true master does not seek to run away from Death. He accepts that he must die, and understands that there are far, far worse things in the living world than dying." -- Albus Dumbledore, Harry Potter and the Deathly Hallows

A comment by staunch on news.YC really clarified this decision for me. Startups are much like the archetypical Hero's Journey: there's the call to adventure, when you get the initial idea for it, there are sidekicks & partners, there are hopefully hands-off mentor figures, there are tests and tribulations and temptations, and if you're lucky there's a happy ending where the hero embraces his destiny, overcomes his competitors, and sells out for millions of dollars. Of course, this is real life and not a fantasy novel, so there's about an 80-90% chance that the hero goes broke and gets another day job, wiser and more skilled yet somewhat embittered.

The critical success factor, though, is that the hero first acknowledges all his doubts and fears and then embraces them. So yeah, failure is a very real possibility. In the storybooks, that means death. In startups, it merely means that nobody likes what you're doing and you're wasting your time & money, and you may go broke.

Big problems are scary. I've found that this has been a significant problem for me. I could do RejectedByYC/Bootstrapacitor in 3 weeks, because I just looked at it as a distraction from Diffle, so it wasn't important, so I could just throw things up on the screen and make it work. I could do Diffle, because once we had finished Bootstrapacitor, it was just a distraction from the game creation engine, so it wasn't important and I could get it up on the screen. I've slowed down markedly on the game creation engine, because this is what we've been wanting to do all along. What if nobody likes it? What if it flops?

I guess the answer is: so what? If it flops, I've built up skills in web design, Python, JavaScript, lots of cool AJAX stuff, etc. I can try other ideas. I have money in the bank. It's not gonna kill me to spend a year working on random startup ideas.

This also answers the question Todd asked me: when are you gonna quit? And the answer is: when we run out of ideas. As long as we have something to do, why not do it?

Objections

I had a long conversation with Frank, and then Sheldon, at work today. Dunno if it was intended to get me to stay or if it was just to let me know some of the pitfalls of startups - it seemed like a little bit of both. Anyway, I want to write down some of the objections they had so I can come back to them and we can perhaps address them.

From Frank:

1. Advertising/sales expenses. It takes money to let people know about your product. You can have the best product out there, but if folks never hear about it, they won't use it.
2. Development costs - it sucks to spend $90M and then find there's no market out there.
3. The company's business is really picking up - I could be missing out on a very exciting time.
4. We should at least validate the market by sending links to an impartial potential customer (he offered his son) before plunging in
5. Much of our hurry may be premature - we can watch our competition, see if they take off, and try to catch up with them afterwards

From Sheldon:

1. We should at least be able to convince angel investors to invest money, even if we don't take their money. If we can't convince them, how can we convince customers?
2. I'm too young with too little technical experience for this
3. It'd suck to spend all this time building a product and then find that we were building the wrong product. All that development effort would go to waste.

One of the biggest mistakes entrepreneurs can make is confirmation bias: disregarding information that doesn't fit the course of action they've decided upon. I'd really like to avoid that trap here, so I'm writing down these objections here so I can come back to them impartially. Unfortunately, almost all of these are just opinions: they aren't factually verifiable, which makes them a bit hard to test.

There's also a problem in that knowing more and knowing way less than a person both seem the same: in both cases, they look stupid to you. I mentioned this problem to my friend Doug when I first joined my last employer: there were business decisions Sheldon made that seemed a little off, but I couldn't tell whether he was dumber than me or way smarter than me. Doug reassured me that he was probably not way smarter than me, but that's not really enough to go on.

I think I have a solution to that: I've e-mailed Sheldon asking for the most influential books/websites/blogs/resources in his company's growth. Because while you often can't tell if a person's opinions are wrong (you have no idea what experience they base it on, after all), you can tell if their reasoning is wrong. If you know what they know and then can point to specific flaws in their assumptions, you can answer the question of whether you're smarter or way dumber than someone.

I'm not willing to wait and see how the competitors do. The problem with these highly viral consumer web services is that they'll sit with no adoption until you solve the whole problem, and then everyone will try to use them at once. Once you've solved the whole problem, there's no way for a competitor to squeak in until another problem manifests itself, because users are happy as-is. Most cases where people say "Oh, there was no market" really are cases where there is a market, but there do not exist services on the market that solve the whole problem. For example, YouTube could not exist without FaceBook/MySpace, easy video-editing software, and cell-phone video, because there was no easy way for users to make and edit videos and no audience for them once they did. Reddit could not exist until the rise of blogs and news sites, because there was not enough freshly-updated content to make it interesting.

Leaving

I gave notice yesterday. Went reasonably well - boss said he'd like to keep me, but he's obviously not going to twist my arm, and we left open the possibility of some consulting or part-time work in the future. I did have to listen to a long lecture about how it's too early, my chance of success in negligible, I don't have the technical chops, etc. Ah well - I did hear some things that I'll want to keep in mind anyways.

A quick selection of quotes I've heard from various people around me when I mentioned I wanted to go full-time on the startup:

"So, mom and I were talking about your startup in the car, and while we think it's great that you're trying - we honestly don't think you'll succeed." - my sister

"Don't quit your day job!" - my dad

"But how are you going to eat?" - Cindelius, a netfriend

"So you're basically going to play the lottery?" - Todd, a coworker

"If you can't even convince me that a market exists for this product, how are you going to convince investors or customers?" - Sheldon, my boss

These quotes are perhaps a bit unfair and out of context - Cin and Todd have actually been quite supportive, and even the boss & family members just want to make sure I'm aware of the risks. But I thought I'd put them up there for posterity's sake. [Edit: Yeah, and they were exactly right. ;-)]

Quitting the Day Job

This is really a work-up-the-courage-to-give-my-boss-notice post, but I also want to jot down some of my thinking, just to clarify things in my own head and make sure that I'm not making a huge mistake.

I had initially wanted to start a startup straight out of college. My idea at the time was for collaborative editing, a la SubEthaEdit but over the web. As it turns out, Google Docs has implemented the same feature now, so it wasn't a horrible idea, but it wouldn't've worked out anyway because I would've just ended up competing against Google. The reasons I didn't start it and ended up taking a day job instead:

1. Upon looking at SubEthaEdit's market again, they weren't really getting widespread adoption. There was some niche interest, but few people using it for actual work, and those who were tended not to care about the collaborative editing features. What failed for SubEthaEdit was unlikely to work for us.
2. I didn't have money. Coming out of college, I had roughly $10K saved from my year at Traxit, sitting in a tax-free municipal bond fund. I had about $3-5K in my bank account from summer work. I figured that legal fees would easily eat $5K, hosting would eat a couple hundred a month, health insurance would eat a couple hundred a month, and I really didn't want to be mooching off my parents, though I did end up living at home anyway. That didn't leave much runway.
3. I felt that I frankly lacked the experience to start a startup. Yeah, I had taken FictionAlley.org's new system from conception to completion (or actually, I only completed it in November after finishing college). But I had no idea what people would actually pay for, how legal and financing stuff works, common mistakes that startups make, how to manage programmers if we ever were to grow beyond just me, or anything like that.
   
4. I'd only taken two projects successfully to completion (Scrutiny and FictionAlley), and FictionAlley felt like it was a big stretch. I worried that I lacked the discipline to carry something as big as a startup all the way through.

So I decided to take a job at someone else's startup and learn how it's done while saving up money. Best of all worlds, except I had to leave my startup dreams behind for a couple years. With luck, I'd do some side projects and something would take off, then I could quit once it looked like it'd be successful.

Fast forward a year and a half to now. The status of each of the 4 points above is:

1. I mentioned our competitors in my last post. Sploder has a forum with a bunch of people that are pissed off because its founder is no longer maintaining the site. GameBrix has gotten some tech press coverage. MyGame has a bunch of games actually created by casual browsers. It looks like our competitors are about to get traction - if we delay any longer, they'll leave us in the dust.
2. I have close to $40K in the bank, another $20K in the brokerage account, and $35K of Akamai stock I could sell. If I were to move out and live like a grad student, the cash in the bank would cover close to 2 years, and then the stock accounts nearly 3 years more (assuming no market crash, and we'd be fucked anyway in that case). That's after paying lawyers for incorporation and buying out the silent partners.
3. From what I've seen at my job and what I've read from other successful founders, startups are simpler than I thought. It basically comes down to three rules: 1.) Make something people want, 2.) Charge more for it than it costs you, and 3.) Fix problems now rather than later. We do 3 and hopefully 1 already; 2 will have to wait because of the market, but that just means we have to keep costs very low to start out. Of course, there's a lot of complexity behind each of the individual points, but that complexity depends heavily on the particular market opportunity. It's not something you can take with you from job to job. We'll just have to develop that expertise as we go along, which means we need time and focus to work on it.
   
4. Since college, I've added Write Yourself a Scheme in 48 Hours, a Netbeans Plugin for work, Bootstrapacitor, the Execution Monitor for work, and now the Diffle flash games site to that. Each of those had places where I wanted to forget about it and read Reddit at the time. In each case, I came back and finished it.
   

I've also tried to eliminate as much risk as I could from the decision to go full-time on Diffle. The way I see it, the various forms of risk inherent in a new business are:

1. Enthusiasm risk. You may get started and then find that you don't like your business idea as much as you thought you did, once you have to start doing actual hard work.
2. Team risk. Your cofounders may have divergent goals, and the team may fall apart.
3. Technological risk. You may not be able to build what you're hoping to build.
4. Market risk. It's possible that nobody will want what you build
5. Economic risk. You may not be able to build what people want at a price they're willing to pay for it.
6. Competitive risk. Someone else may build what people want better than you.
7. Scaling risk. If you build everything way better than everyone else builds it, you may not be able to scale your infrastructure to the demand this creates.
   

Enthusiasm risk was a big worry when I started, and the reason I didn't quit the day job immediately. But I think it's fairly likely that that's behind us: I'm finding I'm more excited by the actual process of working on this startup the farther we get.

Team risk actually happened to us, but we've basically dealt with it. Our 3 former cofounders seem willing to be bought out. It was an expensive mistake, but much less expensive that allocating 50% of the equity to 3 people who aren't really interested in being day-to-day involved with the business.

We've tried to reduce technological risk as much as possible. We are live with the actual website now - it's unlikely that any surprises will crop up there. We have prototyped command-line compilation from XML to Flash, so we know we can do that, and it's nothing more than string manipulation in Python. We've prototyped building a game in JavaScript, and succeeded with adequate performance. I'm working on customizing that game in real-time through JavaScript, but it seems like that should work without major hitches.

We still have to live with market risk. Ideally, I'd stick with the day job until Diffle took off and it was clear that people wanted our system, so we'd only have to worry about scaling risk. However, in the presence of competitors, they are more likely to take off and get users if the market actually exists. By trying to ameliorate market risk, we open ourselves up to competitive risk.

Economic risk is typically not a problem for software startups, because your variable costs are so low. If people like what you build, there will be some way to monetize that profitably. Often it involves selling out completely to a big company, but software that gets used almost always is a net economic positive.

Finally, we're still very exposed to scaling risk. But that'll only get worse if I still have my day job. And if we get to the point where this is a problem, I'll be jumping for joy.

I figure that worst case, I try this for a year, see how far we get, and if it was a complete mistake, I go get another job.

Competition

We've found 4 competitors in the past week and a half: MyGame, GameBrix, Sploder, and GameScene. Each of them is more advanced than us. In GameBrix's case, they've been working on it since at least January 2006, and probably have some sort of funding.

Still no more traction on Diffle.com. I can't really blame people: right now, it has nothing to recommend it over any other site on the Internet. There're a bunch of features I'd like to implement, but it's hard to get a good continuous block of time. I typically have about 20 minutes in the morning while eating breakfast, a half hour before dinner at night, then in theory I've got 2-3 hours before going to bed, but it's usually broken up into hour chunks by shower/dishes/taking out the garbage/etc. It's hard to get into flow with only an hour, particularly at the end of the night.

(For a while I was doing okay by timeshifting things and going to bed immediately after dinner, then working in the morning. But this only worked while things were relatively light at work. I find that I need more sleep the more that I program, so I was going to bed at 10 and waking up at 8, the same time I would've woken up had I gone to bed at midnight.)

I've decided that I'm going to quit my day job. Planning to give my boss advance notice tomorrow, though it may be a month or two until I'm actually done. We have to get an IP release signed before I leave; Mike is talking to a lawyer tomorrow night.

We're going to try for yCombinator funding again. Obviously I hope we get it, though having been rejected by them 3 times before, I'm not too optimistic. Mike will quit his day job for the program if we get funding, in February if not.

Still no more traction on Diffle.com. I can't really blame people: right now, it has nothing to recommend it over any other site on the Internet. There're a bunch of features
I want to implement, but I don't have a solid block of time to implement them.

Launch

Long stretches of time without posts are good things. It means I'm working on coding rather than blogging.

I suppose I should've put up an entry about the launch when we launched, but a.) I was too busy and b.) there really wasn't a clear launch date...we sort of slid into it, and we're still sorta sliding into it. This just happens to be the first time I've got time to blog instead of code. So I'll try to reconstruct what's happened since the last entry, almost a month and a half ago. There's bound to be a useful lesson in here somewhere...

We went live on Tuesday, June 26. "Went live" as in "Okay, password protection is off, you can tell your friends about it." I suppose our official launch date was July 1st: that was when Mike put one of our games on Digg to test the waters.

As of the last post (May 31), we were "Just about to launch - this is the last feature we need, really." This seems to be a common feature of startups: FictionAlley was "ready to launch in a couple of days" for about a month before it actually launched, my day job has been "ready to launch" for the last two months but with little actual activity on that front, and Diffle was "one day away from launch" for about 3 weeks. So it's worth looking at the Subversion commit log to see where that time was actually spent.

On May 31, I was working on auto deployment. I didn't actually commit those changes until Jun 2, my birthday, and then it's only "beginnings of auto-deployment". I finished (with a big ? in my commit log message) on June 5, then we had to fix bugs in the main production script that only showed up after deployment. June 7 involved adding the ability to change passwords (oops! how could I forget that), June 8 was some bugfixes, and June 9 began a pretty page for handling internal server errors, which I didn't actually finish and debug until June 12 (there were no commits between June 9 and 11 - I was at Chris & Jess's wedding).

The next week was all bugfixes - there were a lot of them, apparently. I think I actually removed the password protection on June 20 (the same day I added the custom 404 not found page - there are 8 commits that day, I must've did a whole lot of other bugfixes too). There are a couple fixes there that IIRC came from suggestions by Mike's girlfriend Sandy, so it would've been open to at least her. Then I had to convert all templates to precompiled Cheetah templates to fix a unicode encoding issue - this was the last bug before launch, I discovered it about an hour before we were about to go live and decided it was enough of a showstopper to postpone the launch. It took about 2 days to convert everything to precompiled templates, then we went live on June 26, though we didn't actually tell anyone about us.

I went on vacation - no Internet access - for the 4th of July week, which was one of the main reasons we didn't actually tell anyone. Spent the time prototyping the game creation engine - I should jot down some thoughts on that soon, because they're undoubtably wrong. Mike dugg a game anyway, to see the response. We ended up getting like 700 unique visitors from that, but the site really isn't sticky. The vast majority (like 93%) came and left without checking anything else out. Since then, we've been holding steady with about 20-40 uniques a day. I suppose that's somewhat encouraging, that at least *somebody* checks us out daily, though it's not much. Mike and I both think we really need the game creation engine in order to take off.

Aside from that - we had to switch from Cheetah to Mako because Cheetah offers very poor handling of AJAX fragments. There's no real facility in Cheetah for libraries of mixin HTML fragments: basically, each def needs to be either on the page or in a parent class. Mako is much more flexible, with both inheritance and namespaces, and also seems to have more robust unicode support and an easier API.

I should start the main Diffle announcement blog so it's not just a blank page. It's at diffle.blogspot.com, and will be the public face for announcements and status updates and such. This will continue to be more internal reflections and so on.