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 :)
Thanks. I also think it’s important to hear about the failures since it really is all too often we hear about the next digg or facebook..
I just hope this article can be helpful to those who are doing their own startup so they can avoid the same mistakes I made.
I wrote it in part to remind myself to never make these same mistakes again and in part to give back to the community. I know there are plenty more like me out there and I’d love to hear their stories as well…
Some time ago I opened a thread about failure of startups but it did not gain any attention. I would really like to hear more about failures and aftermaths of startups.
This is a brilliant piece imho because not only is it a lesson to the community but because the example also edifies what the gurus are telling us. Agreed, it would be great to see more stories like this. Maybe one of the "incubators" could take this on?
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.
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.
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?
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.
"if the shiny feature you want to implement is not absolutely necessary for your solution and it will take more than a day or two to finish then move on"
small hooray for shiney, unnecessary features that do get done in a day or 2 though! keep 'em guessing. =)
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.
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.
I think my original issue with iPhone dev was that POS NDA Apple had originally. It made the web a virtual wasteland for good info and advice on programming pitfalls and code snippets.
Coming from python and c# I was obviously spoiled =)
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.
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...
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.
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.
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.
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.
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.
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.
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.
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!
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 :)