Mobile messes up the lean startup seed funding economics | Hacker News Reader

Mobile messes up the lean startup seed funding economics

theonda.org

28 pointsspeek21 comments

You can "fake" mobile support using Twilio. It will not have an experience as good as a native smartphone application, but the cost is lower by (plural) orders of magnitude, and the reach is far greater.

I'm writing Appointment Reminder, which features a scheduling interface (in a web app). I have heard from customers that it would be really, really handy if they could access their schedules while away from a computer. One of them specifically asked for a Blackberry app.

I could write a Blackberry app. And an iPhone app. And twelve Android apps. And... no, wait, this is insane. I have enough on my plate just getting the underlying service and web interface to work.

Instead, I am writing something responsive to the underlying need ("I need to check my schedule when not at a computer") with Twilio. Call the number you programmed into your phone, hit 1, bam, here is your schedule for today. That gives me 100% coverage on all handsets, including feature phones, for approximately an afternoon of work.

Now, if that feature blows the doors off, it might be worth surveying my customers about what phone they have and implementing e.g. an iPhone, BlackBerry, etc app as resources permit. If nobody uses the feature at all, or if I can't get the marketing for Appointment Reminder to the point where I have any customers to worry about not having an iPhone app, then I didn't spend several tens of thousands of dollars in vain to learn that.

Is a twilio "app" better than an iphone app shell that runs a slimmed down version of your web app?

Accidental downvote . . . I agree that this seems more practical and almost as easy.

If that works for your purposes, wonderful. For my purposes, it sounds like "Teach yourself ObjectiveC so that you can write a version of the site you have to maintain in parallel, for the benefit of iPhone owning customers who may not exist."

I think he means something like, "Why not build a simple webapp that prints out a users schedule, that they can view on any phone, and can save as an icon if their phone supports that (iphone)"

It solves the problem you're trying to solve, requires minimal effort and is cross platform.

If your app is basically a webapp that you want to be accessible from mobile devices, you're best off with a mobile stylesheet for the web app. It can be a timesink, but definitely less of one than the multiple FTEs you need to support native mobile apps.

To me, though, the really interesting stuff in mobile are the markets that simply aren't possible for desktop webapps. Things like Shazaam or Bump, and probably lots of other things that haven't been discovered yet. These things simply can't be done as webapps, because you don't have the hardware support necessary to access those features.

It's like how when the web came out, everyone used it as a glorified storefront, with e-commerce everything, because that's what they were familiar with. It was only once it'd been out for ten years or so that we realized it replaced the socializing part of going to the mall and not the shopping part. It seems totally obvious today that people would use the web to talk to each other, but it wasn't so obvious in 1995.

I hate the idea of installing a million apps for every little service out there. If you ask me, building a simple mobile website which caters to the most common things people will want to do with your site. I think Google calendar is a good example, and both Commonwealth Bank and Bendigo Bank in Australia have done good mobile sites.

Frankly the trend towards device specific appllication support is a massive PITA. It's like we only just got over the problems of people having to choose which web browsers to support and we are approaching some semblance of standars when Apple and the iPhail come along and ruin it all over again. now everything is apps apps apps and device vendors (especially Apple) are actively taking steps to prevent people from using solutions that make cross platform deployment easier.

Boycott the apps and return to reason!!!

If it's a PITA to you, let someone else deal with it and reap the benefits. It's not up to you to determine what is best for users. If users are willing to pay for device specific apps then let the market cater to them.

It's your company, you don't need to cater to 'iPhail' users if you don't want to. Let them and their revenue go somewhere else.

Why the heck would anyone target mobile web over the regular web? Unless your application is specifically designed for mobile usage it seems ridiculous.

Mobile is actually a big deal now, but it's still a far smaller deal than the non-mobile web already has been for many years. The hype only makes it seem as important.

Not mobile web. Native mobile apps.

Mobile web will also be important soon too though.

Even mobile apps. Take a recent cool YC company: Hipmunk. Why the heck would they make a mobile app version before hipmunk.com?

Thanks for the shoutout! Yes, the web app was definitely first priority. But apparently mobile is a huge recent growth area for travel search sites. Folks evidently want to search & book from their smartphones -- but it's still not as big as web (yet?).

This prompted me to go back and search Kayak's S1 filing[1].

From that we learn that mobile represents 1% of their revenues (7% searches). And that's for Kayak, whose mobile app has been hugely successful (4 million downloads).

Obviously it's a big growth opportunity, but for Hipmunk you have even more opportunity for growth (and revenue!) on the non-mobile web. Kayak less so.

"Queries conducted on our mobile applications accounted for 7.0% of our total queries for the nine months ended September 30, 2010. However, mobile applications accounted for less than 1% of total revenues during that period. We believe mobile applications will continue to gain prominence, and we expect to continue to commit resources to improve the features, functionality and commercialization of our mobile applications. We also believe over time mobile applications will begin to contribute meaningful revenue to our business."

...

"KAYAK mobile applications have been downloaded nearly four million times since their introduction in March 2009. For the quarter ended September 30, 2010, we had over one million downloads, representing growth of 152% compared to the same period in 2009."

1. http://www.sec.gov/Archives/edgar/data/1312928/0001193125102...

Yes, you will need at least a FTE for each device. 1 x iphone, 1 x ipad, 1 x android, 1 x android tablet.

Then if you start talking about blackberry, symbian, palm, etc. you start to look at a team of around 10 just to provide mobile access.

Not good, nor bad I think. Just the way it is.

HTML5 apps that outperform native mobile apps is not coming soon. Native apps are here to stay for 5+ years.

Most people will be fine with one good developer working on both their iPhone and iPad versions. I do think that's a full-time job though.

Depends if you want to make use of a different UI for iPad AND make both of them excellent.

HTML5 web apps delivered over the network, or bundled as native apps using http://phonegap.com are good enough right now.

Use jQuery Mobile, or jQTouch, or joApp, or XUI, etc.

Don't make the Lotus 1-2-3 mistake: http://www.joelonsoftware.com/items/2007/09/18.html

"IBM was starting to ship a few computers with 80286 chips, which could address more memory, but Lotus didn’t think there was a big enough market for software that needed a $10,000 computer to run. So they squeezed and squeezed. They spent 18 months cramming 1-2-3 for DOS into 640K ...

By the time [Lotus] 123 3.0 was shipping, everybody had 80386s with 2M or 4M of RAM"

Same thing applies to smart phones at the moment.

This depends on your product / idea. Both Android and iPhone have a substantial install base, why not pick one and test first?

If you get traction, then expand etc. Choose the platform that makes more sense for your app (capabilities, payment options).

As for outsourcing, depends on the complexity of the app. Basic apps you could use a consultant off CL for some quick prototyping.

IMHO using consultants is OK, if (a) speed is essential, (b) you can build and test the code yourself, but just don't have the time (c)Make sure you have a rock-solid contract

If you're building a web app that absolutely requires a mobile component that can't be delivered via HTML5, then yes.

Simultaneously, mobile distribution platforms like the App Store have created an massive opportunity for creative developers out there.

How many startups out there don't have a clearly defined use case or have a use case that is precisely split evenly between desktop/iPhone/iPad/Andriod, and absolutely cannot get traction with out a tailored experience on each platform?

I'd hazard a guess that the answer is none.

It's not a big deal, if the primary users are desktops write for the web first. If the primary users are going to be mobile write for mobile first.

If you have 'the best. idea. ever.' then you should have no problem securing the funding for a 3 person startup.

Since you probably don't and are going to have to do a lot of iteration think about how your service is going to be used and pick the right platform first.

Stop thinking about how to get your millionth customer and start thinking about how to get your first.

Broadly, guys, for a lot of the interest in 'mobile', although not all, I very much don't 'get it'. Where am I going wrong?

For my project, I want happy, "engaged" (F. Wilson, AVC.com) users who see my work as a "must have" or at least as something quite important to them. Then, my work needs a good enough 'user interface' (UI) and to provide a good 'user experience' (UX); for these two, the simple, quite standard HTML and a simple laptop computer or better are fine, but small, handheld, mobile devices look awful: The display and keyboard are too small, and access to the rest of the user's often crucially important 'full computing environment' is too limited. There are also some new, severe security problems.

While there is money to be made in mobile, I see it easier to make money where my users have a laptop or better with a standard Web browser.

Generally I see it better to provide new 'content' the users will like a lot, via a standard Web browser on a laptop or better, than to severely throttle the content and severely hurt the UI/UX just to provide access on a handheld device. That is, I trust in the CONTENT and not the 'form factor', and definitely don't want the form factor to hurt the rest.

Net, I definitely do not believe in "mobile first".

Where am I going wrong?

Reply on news.ycombinator.com