

Mobile messes up the lean startup seed funding economics - speek
http://theonda.org/articles/2010/11/24/mobile-messes-up-the-lean-startup-seed-funding-economics

======
patio11
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.

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

~~~
patio11
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."

~~~
jfeldstein2
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.

------
dools
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!!!

~~~
fleitz
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.

------
staunch
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.

~~~
chadp
Not mobile web. Native mobile apps.

Mobile web will also be important soon too though.

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

~~~
kn0thing
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?).

~~~
staunch
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...](http://www.sec.gov/Archives/edgar/data/1312928/000119312510262521/ds1.htm)

------
chadp
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.

~~~
staunch
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.

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

------
rjrodger
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.

------
anmol
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

------
stevenwei
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.

------
fleitz
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.

------
HilbertSpace
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?

