MADE IN DETROIT

The most interesting thing to me about the iPad announcement a couple weeks ago has nothing to do with the device itself (at least, not directly). In my opinion, it’s that in the two or so weeks since the announcement, the amount of interest surrounding Mobile HTML5 apps has increased tremendously. Going into it, I would’ve expected the opposite to happen: people would’ve been jumping further into the native app bandwagon. But that just wasn’t the case.

Looking back on it, here’s why I think it happened. One reason is obvious, but I think it might be more subtle than just the obvious answer:

• The obvious answer: Lack of Flash. The lack of Flash on iPhone and iPad has caused quite a lot of anger from developers and users alike. The fact that Steve Jobs brought up a web page with a big non-working Flash object during his demo didn’t help things. HTML5 bridges this gap with its video support. But I don’t think this fully explains it.
• Less obvious answer #1: I think a lot of developers are still feeling pretty burned by some of the less than gracious tactics by Apple and their approval process and heavy-handedness. For a while it looked like things are getting better and then they went and did things like lock down geolocation for ads. I think developers are looking for an excuse to head towards HTML5 and the web.
• Less obvious answer #2: The new form factor of iPad means that every developer has a brand new resolution and screen size for which we need to develop. This might not be a huge deal for many developers, but it’s a big time-sink for the best developers. Add in the fact that Android seems to be gaining steam and you’ll see that it’s not even close to a “write-once, run-anywhere” environment. You may not be able to control everything about a mobile web app, but for the most part you won’t have the same overhead as writing native apps specifically for iPhone, iPad, Android, BlackBerry, etc.

I’m a big believer in the web, and I think the web will win just as it did on the desktop (and I think Google is showing how great the web can be with Google Voice for iPhone and Google Buzz web apps). It might take a few years, but I think it’ll happen.

Sometimes Chris, Brett, and I feel like we get no press love for AppStoreHQ. We’re the biggest app discovery service, yet others are being covered way more frequently by the “elite” tech blogs. Truth be told, however, in less than a year we’ve received some great coverage, so we’re not complaining one bit; we just think we have such a great service with awesome features that solve real problems for users and developers (we’re passionate like that).

I thought it’d be somewhat interesting to see the relative effects of some of the bigger, more respected journalists and sites who have linked to us over the last 6-8 months. Below is that graph. I’ve labeled the source, the date, and whether the link was “primary” (that is, the article was about AppStoreHQ or app discovery and included us) or “secondary” (the link is probably just to an app detail page or something similar). I summed the amount of traffic we received in the 7 days after each link was published.

There’s a lot of interesting data in there, in my opinion. First, TechCrunch is obviously big, but Boing Boing blows it out of the water in terms of traffic sent. NYTimes Gadgetwise is large, but I would’ve expected larger. I imagine a link from their newspaper articles would be tremendous. Then there are some surprises, like how much traffic Pocketgamer sent, or how little Hacker News sent (we’ve been on the front page a few times; I chose the time with the most traffic sent). Granted, we were never #1 on Hacker News, so I bet that contributes to it.

Interesting stuff. I’d love to hear how this compares to your experiences, and which sites sent the most/least traffic for you.

AppStoreHQ isn’t really a virtual company, but it’s close (especially for me): My co-founder and our first employee both work from our office in Seattle, while I work from my apartment in Los Angeles. It’s definitely an adjustment, but I we’re doing well with this set up.

Here are some tips that have helped us over the past year or so:

• Begin by working together. Chris and I spent a few months together in the office in Seattle before I moved to LA. Before that, we spent upwards of a year chatting off and on about business, startups, etc. This time together helped us get used to our styles and understand the primary objectives of the business in a way I’m not sure we could’ve done purely virtually.
• Know when to use various tools. Email is great for things you don’t need a response to immediately. IM is good for getting quick answers to simple questions. Voice is the best for hashing out more elaborate issues or arguments. In-person is the best for long-term strategy and planning. Learn when to use each of these tools and you’ll have a successful virtual startup with great communication.
• Skype video chat is your friend. You’re running a startup, so you probably have a new laptop. It probably has a web cam. Use it. Seriously, Skype video chat is fantastic: being able to see your teammates faces and reactions is an amazing tool for virtual teams. It also has a great Screen Sharing feature to show-off half baked ideas.
• Make sure you’re in-sync with daily video chats. Every morning the AppStoreHQ team logs on to Skype and does a quick video chat. We go over projects in progress, recently completed, and upcoming. We make sure everyone on the team understands what everyone else is working on and how it’s going. This 15 minute video chat is, in my mind, probably the single biggest key to our success working virtually. Getting on the same page every day is so important.
• Make your progress transparent. We use a Google Spreadsheet to keep track of all our projects and where we are in each of our tasks. Keeping that up to date gives everyone, regardless of location, insight into how everyone else is performing and how close each project is to launch.
• Get together in person every once in a while. Once every month or month and a half, I head up to Seattle for a few days and meet face to face with the team. We spend a few hours going over higher level strategy, thinking ahead a few steps. We go out to team lunches. Things we couldn’t otherwise do effectively over email, IM, or Skype.

These tips are simple, but they’ve helped us a ton. You have to be committed to running a startup virtually, but if you are, you can be successful.

The future of mobile apps is definitely an area in which I have a lot to say. Specifically, my views around HTML5-based mobile web apps and native apps. Here’s my personal overview of the world as it is right now.

Overview

Chris and I often talk about how there’s a strong correlation between what’s happening right now in mobile apps and what was happening to the web around ‘96-‘99 or so. That is, it’s exploding, discoverability is hard, people want to be on board but aren’t sure why/how yet, etc. Many, many similarities.

But there are also correlations to even earlier than that, such as the OS wars of Windows and Mac. Right now there are many platforms (Apple, Android, BlackBerry, Symbian, Windows Mobile, etc) all gunning for the apps, while developers are trying to increase distribution. To do so, developers have to rewrite their app — mostly from scratch — for each new platform. Back when the web came around, people hopped on thanks in part to its much nicer write-once-run-anywhere feature (disregard browser incompatibilities here). We’ll see the a similar transition with mobile apps (though not necessarily to the same extent).

There’s plenty of reasons for apps to be native, especially over the short term: access to the camera, better/faster/easier graphics (read: games!), multi-touch. But there’s also plenty of reasons for apps to be web-based: ease of maintenance, write-once-run-anywhere, freedom from approval restrictions.

HTML5 and open source libraries like PhoneGap really start to blur the lines between what is necessary to be done natively and what can be done from the web. As developers begin to learn these new tools, we’ll see some really impressive new apps come to the web (Google Voice), but there will remain the need for native apps, too.

MobileHTML5.com

On that note, because mobile web apps are ready for prime time, I’ve decided to start a new tumblog, MobileHTML5.com. The goal is to provide links, videos, quotes, and hopefully some articles on how to get started and keep up on writing great mobile web apps. Check it out, subscribe, follow, etc. And let me know what you think.

AppStoreHQ

Similarly, if mobile web apps are going to explode, discoverability will be a problem. Luckily, I know of just the site to help with that sort of thing. ;) Today we announced that we now include mobile web apps in AppStoreHQ’s database. We’re starting with just one example, the recently launched Google Voice for iPhone. You can now search for web apps, browse web apps, learn about each web app, and get connected immediately to the app with a click of the mouse (touch of the finger, as it were).

If you have an app you’d like us to include, we’re starting with a manual inclusion process, so just email me and we’ll try to get you set up as soon as possible. In the near future we’ll make this much easier for developers. :)

I said last week that February would be blogging month, but today came and I felt as though I had nothing to write. Still, I couldn’t start the month off on the wrong foot, so I’m beginning with a softball…

Every day we use at least a few tools to help run AppStoreHQ:

• Google Spreadsheet: We have a “master” spreadsheet that helps us manage all the ideas, features, and products we’re building, have built, or want to build. There are 3 tabs: Backlog, Roadmap, and Completed. Backlog is where we keep any and all ideas about what we want to do. Nothing is too big or too small to go here, all the way from bugs to “personalized recommendations.” Roadmap is where we keep track of the projects currently in progress or just about to begin. While the Backlog is tracked at a “feature” level, the Roadmap is at “task” level (where many tasks equal a feature). Each task has a time estimate (no less than one hour and no more than one day) and a “time left” estimate. This simple system works surprisingly well to keep us on track, informed, and cranking out the features, especially considering the various levels of project management I’ve used in the past (ranging from sticky notes to trac to FogBugz and on and on).
• GitHub for source code management. We host our code, a few docs, as well as do code reviews, etc.
• AWS: Our live site runs on AWS: EC2, EBS, S3, and SQS.
• Rails.
• Solr for all searching and browsing.
• Capistrano for all deployments.
• Google Analytics: At a price tag of free, this is an amazing tool for tracking your visitors. It’s quite simple to pick up the beginner features, but provides tremendous amounts of power user features as well.
• Vanity: A tremendous Rails based A/B testing framework, Vanity has helped us optimize various parts of the site.

Like I said, starting with a softball of a blog post. I’ve started to think of some better post ideas, but I’d really love some more, so please, ask me anything.

Last night on a flight from Seattle to Los Angeles, I decided to make February a month of blogging. Everyday I’ll write at least one post here. The posts might be long or might be short, perhaps an essay or perhaps just a bulleted list of links or a quote I found interesting. Whatever the case, I want to create content at least once per day.

I have some ideas of things I want to write about: I’ve been keeping a (short) list of things I’ve learned over the last 9 or so months of running a startup so I’ll definitely include some of those, then there are probably some posts about software, sports, Los Angeles, the mobile web, etc that I’ll add in the mix to keep some variety. I’m sure I’ll still be hunting for ideas, so please ask me anything.