

The number one reason my startup failed - fjabre
http://www.teabuzzed.com/2009/08/the-number-one-reason-my-startup-failed/

======
chinmi
It’s really nice hearing from failures from time to time. These kinds of
stories don’t often get out, but they’re very educational on so many levels.

Especially now when all too many people become so easily enthralled by success
stories the likes of Google, Facebook, Youtube, Digg, Twitter, …

It can happen so fast, losing oneself in wishful thinking, losing all reason
in the process. I’m speaking from experience, this story really relates to me
(although my project isn't as far down the line as yours yet).

If there is something like a Startup Failure Anonymous group, I would like to
join it :)

~~~
jacquesm
The last weeks have actually seen a number of those:

TipJoy:

<http://news.ycombinator.com/item?id=776978>

snaptalent:

<http://news.ycombinator.com/item?id=768725>

you vs me:

<http://ryanleland.com/2009/08/post-mortem-you-vs-me-com/>

and one more:

<http://news.ycombinator.com/item?id=723834>

~~~
jasonkester
And one of mine from a year back:

<http://news.ycombinator.com/item?id=227400>

------
physcab
"So the number one reason my startup failed was: I was distracted by a cool
and shiny feature that didn’t solve anyone’s problem. "

~~~
fsniper
IMHO It's not the real reason behind the fail, the real reason is not using
the limited resources for gaining a ramen profitable state. If you do not have
"unlimited" or more than 6 or so months of funds to run the company you can
not play with luxury items. For this particular case playing with a "luxury
input style" not any means necessary for the problem or the application. This
luxury input style feature is a monster funds eater. May be the application
could run on any vps for years for a fraction of the funds the company burned
for this monster servers. Some engineering and planning in time could help and
prevent this failure.

~~~
fjabre
In essence we are in agreement. Better goal planning sure would have helped.
It certainly may have kept me focused on my initial goal. The unfortunate
reality was that I went wrong very early on in my thought process.

The "cool" feature I wanted to add and implement for the main app should have
been filtered out immediately since it did not really add to the core need I
was addressing.

That's what I failed to realize. The feature I wanted to add became the main
goal and the main solution took a backseat. From that point forward all my
thought processes were biased relative to implementing this feature. This of
course is what I believe was the single biggest reason that led to its
failure.

Who knows if I would have been successful otherwise. Maybe.. maybe not... It
might not have been the next digg or even close to that but I'm sure I could
have gotten to ramen profitable state. I will make a second attempt soon,
minus the shiny features this time...!

p.s. Purchasing the servers was besides the point. I should have never even
gone that far. I never would have purchased them had it not been for that
feature.

~~~
fsniper
I'm sorry for your failure. But it's a win situation for you, a costly one
perhaps. For your next try you will be wiser. Any sane man reading this will
be. Thank you for sharing this event. I think it must be hard to admit
failures.

Better luck for the next run.

Also would you like to share more about your situation after the failure? Your
economics, how you handled failure in psychological sense? Your relatives
reactions etc?

If it's rude to ask i'm really sorry.

~~~
fjabre
No problem at all fsniper..

I'm an eternal optimist so I don't suffer from having failed. It makes one
feel alive actually.

Economically I'm wounded but still alive and healing. Without being too
specific I am 10s of thousands in debt because of my failed startup but not
all is lost. There is a lot of reusable code and designs for the second time
around =)

My family and friends understood when I told them what had happened. I have
pointed them to this article actually.

My situation now is revving up for round 2..! ;)

------
mixmax
His first point _"iPhone app development is not trivial._ " can be shortened
to _"development is not trivial."_

A lot of people, including me, have made the mistake of thinking that creating
the product is simple but fail to realise how much work debugging, polishing,
designing etc. is. The devil is in the details.

~~~
sid
That is so definitely true. You dont know how many people i am working with at
the consulting company i work for that would say ...

"why is this vendor charging X millions for this crappy software, i could have
done this as a uni student" the software may be _crappy_ but they dont realize
the amount of work that goes into getting the application polished, having
correct messages for all actions and making it generally user friendly. Also
the fact that it does the job that someone needs done is why someone is
willing to pay X millions for it.

The devil is definitely in the detail ...

------
ujjwalg
We went through a very similar phase for our startup which is also about
developing iPhone/desktop/web apps. We have a lot of shiny features in our
apps like syncing across platforms, real time percentile scores, meetup
features, turning the iPhone screen into a scratch paper etc., most of which
are useful but given the fact that we were bootstrapping, got us into a deeper
and deeper hole. If we wouldn't have found an awesome developer we would have
to end our startup too.

Good luck for your future endeavors. You have learnt a lot from this. Don't be
disappointed and keep trying.

~~~
fjabre
Appreciate that. I am already in the process of trying again.

I think I also found an awesome developer to help out but I just directed him
the wrong way.

The problem was I didn't find a co-founder, a person that could share the
business and funding responsibilities with me.

Why..? I don't know. There were one or two people that came close but I knew I
wouldn't work well with them. It's very important to work well with whoever
you partner with of course.

Ironically the people I felt I could work well with didn't really fit the bill
in terms of programming ability or skill sets...

------
zaidf
Awesome read!

We're dodging this problem by shelfing most so-called shiny features till we
are making money. Thing is shiny features can be really useful--but once they
take off, you are too busy maintaining them than figuring out how to make
dollars that will fund the shiny features.

In some cases the shiny features and the $ makers are not mutually exclusive
and there is definitely a lot of gray.

------
chmike
My impression is that the main reason of your startup failure is that it ran
out of money. It seems you have a valuable product in your hands and a
potential for a successful startup, since you had significant user interest
when the application was free.

If you manage to provide the service and run your startup at the cost of a
reasonable fraction of your salary, you would never meet this "end of money"
wall and your startup could run forever.

So first, check out to cut the costs to a minimum, eventually offering a more
modest service, especially if it's free. User will understand this, as they
will understand that an extended service would require sharing the costs of
hosting. You should then make sure the benefit compensates largely its cost,
from the user perspective of course.

You wrote that there was no need for such service. How do you know ? The users
could come up with a usage, and thus a need, you didn't thought out before.
This is what you can gain from offering the service for free. Collect feedback
and suggestions, you might find gold gems and perls in it.

The freemium model would make sense, if you can keep the cost of free service
to a minimum. It is preferable, if you can manage it, to provide the service
without depending on fixed amount of investment money that will be running out
soon or later. You can achieve this by reducing the cost to a reasonable
fraction of your salary.

That's the plan for my startup. I will start by hosting the service at home
and thus without hosting cost. If there is income, and its progression ensures
break even may be reached, then I'll invest in the next step, and so on.

The trick is to make an investment only if a positive money flow balance is
restored shortly after it, progressing by steps, minimizing the risks of "end
of money" failure. With this policy, your startup can only fail because of bad
luck, like being hit by lightning for instance.

------
idlewords
There's a lot to be said for having users pay real money right from the start,
no matter how minimal your service, as a way to avoid getting seduced by cool
but unmarketable features.

~~~
fjabre
Yeah I can't stress that point enough. Just get enough core features in your
software, get some half decent design for it, and start selling..!

You can always improve incrementally but even just signing up a handful of
payers in the beginning at a discount is huge. It proves that your idea is
something people are willing to pay for.

------
chaosprophet
It just appeared to me that perhaps you should have tried delegating the
speech recognition to the iphone app. That way you would just be dealing with
transcribed text which would have been much less of a load on your servers.

Anyway, it was nice to be reminded that features are always secondary. Hope
you do better on your next startup.

~~~
holygoat
On-device speech recognition is harder, works less well, is more expensive,
and is generally not the usual approach. If you need network connectivity for
your app, it's usually simpler and better to send off the audio.

~~~
fjabre
Yeah I can testify to that.

We tried on-device speech rec. The unfortunate barrier to entry for this
technology is something called Acoustic Models which are basically normals
data collected from voice sampling. The bigger and better your AM, the more
accurate your speech rec. A good sized AM could be gigabytes worth of data and
we're just talking about US English.

Not only that but the actual recognition itself is pretty intensive CPU/memory
wise. Sure you can have local speech rec as Apple does on the 3GS but that
speech rec is pretty constrained: only having to recognize several hundred
contact names or song titles and even then has a hard time. Try loading up
thousands of contacts or songs on your device and see how well or consistent
it is.

At any rate, AMs are like gold and pretty much all of them are proprietary.
Ever think why Google offers a free 411 service..?? They want to build out
their proprietary AMs.

So you either have to make your own AM - very hard to do - or roll with an
existing solution, most of which are server based. I used Lumenvox
(lumenvox.com) since they seemed to be the most developer friendly and were a
pleasure to work with. The Dragon guys would sooner compete with you then sell
you a product.

------
japetheape
nice to hear such a story, indeed they don't come out often... i recognise the
focusing on feature thing. I and some friends/colleagues built a few years ago
a website were musicians could record online video jams, someone recorded a
video, another one another and in total 4 streams were recorded and played at
once split screen. It worked great and some great tunes were recorded. But it
also didn't provide a solution to a problem and the project is dead now, dead
pool oww yeah. We didn't invest any money in it, only lots of time, so nothing
to worry about. When I have a little new project in mind, I now know I have to
think if it fulfils a need, most of the time it doesn't and then it's very
difficult to let that idea go. About my project: hey I learnt a very important
skill and he will also! Failure makes smart!

