7 lessons from my first app failure

In the summer of 2013, I had the idea to make a mobile app, so I called up one of my friends and got to work. Over a year later, we launched Texty Time. The project took so long and not too many people used it, so I decided I never wanted to touch or even think about it again. Recently, I was reading @levelsio’s blog on how he planned to start 12 startups in 12 months. For a lot of these projects, he had a project debrief page where he talks about what he learned from each of them. Suddenly, I realized that I myself have attemped (and failed) at making something akin to a “startup” as well (albeit very very humble and basic). This is the story of what I learned.

As James Joyce said:

Mistakes are the portals of discovery

I didn’t even realize it was a “failure”, because I didn’t consider it to be a serious attempt. However, I realized that it would be an even bigger mistake if I failed to learn from the experience. So instead of running away from failure, here goes my attempt in trying to extract what lessons I’ve learned from my first app failure.


Throughout the development process, what affected us the most was our crippling technology, inefficient workflow, and overall lack of a market need for the product itself.

Crippling Technology

Technology was a big part of what determines if an app succeeds or fails. First of all, there was the issue of being unfamiliar with the technology we used. I had never coded for Android before, so we tried a few different things at first.

Coming from web development, I tried PhoneGap because I believed in the power of HTML5. This was a mistake, because although it sounds great in theory, there was always too much lag and not enough control over how things would be rendered. The fact that we had to rely on web frameworks within a webview on an Android phone was bad enough, but dealing with a rapidly changing PhoneGap core made it even harder.

Lesson #1: Do not use technology that is relatively immature and rapidly changing.

After a couple of months or so, we decided to switch to coding in Java on native Android so the user could enjoy a more responsive and lag-free experience. I soon realized that working on Android in Java was painfully low-level, and the Android API itself was too rigid (not good for prototyping fast). Android was also prone to version fragmentation, so we experienced some API changes throughout our development. Getting the app itself onto the app store and making sure we had all the in-app payment and everything setup properly was also a hassle. There was also the issue that Google could change anything on us at any time.

There were two major lessons here:

Lesson #2: Do not use technology that is slow for prototyping.

Lesson #3: Do not develop in a market where there is a lack of control.

Inefficient Workflow

We were just two people with full-time occupations doing this on the side. What we lacked was a sense of urgency. We probably could have done everything we did in 20% of the time. There were months in which we made no progress at all. This is not only an issue with personality, but also of vision and values.

Lesson #4: Set hard deadlines to build a sense of urgency.

Lack of Market Need

There was no clearly defined target market. It just sounded like something cool that people would pay for. We were banking on people who might be desperate to know about how their relationships were like through their texts. However, it was obvious that we overestimated the market need for such a product. As Seth Godin put it, you need to understand the “tribe” that will become your loyal early adopters.

It wasn’t enough to simply know that there might be desperate individuals out there. We tried to scratch our own itch because it was something cool that we wanted. That’s all fine and good, but we should have prototyped and launched fast to really figure out how much market need there really was.

Lesson #5: Do market research.


Pricing Too Low

We set a freemium model for the app because we were scared people would not download it. In retrospect, we should have charged full price for the app. We were very timid and were scared that nobody would buy it if we did that. I now think that if what you made is not worth charging full price on day one, then you are almost certainly doomed. Social networks and other types of entrepreneurship aside, note that we are focusing on solo entrepreneurship through coding apps or webapps.

Lesson #6: Aim to charge on day one, or re-evaluate your idea.

You could also use ads, but that is a mixed bag. Unless you know that people will have your app open for long periods of time, this is likely not going to work for you. This works well in games and radio apps, but for almost everything else it is unlikely to be a useful strategy.

Lack of Focus

Admittedly, this is still an area which I don’t know much at all. However, there is a lot of great content out there, and I intend to read it. When we were marketing this app, we just haphazardly sent it to a lot of people we knew along with some random bloggers. There was no strategy at all, and we probably should have asked for more advice on the web along with doing a lot more research on our part. Later on, we even dumped some money into Google Adwords and Facebook ad campaigns, but to no avail.

Lesson #7: Have a focus and strategy in marketing.


Launching fast eliminates a whole class of problems.

This was a very costly lesson. A year of your life (albeit mostly part-time) is a high price to pay. A lot of these problems and issues would have come to light much sooner if I set myself a a tight deadline and prototyped fast. I now realize that prototyping fast is not just for the sake of efficiency, but it also completely eliminates a whole bunch of problems.

In other words, a lot of the problems I experienced above could have come to light a lot sooner or even completely avoided if I only just prototyped faster and launched sooner.

comments powered by Disqus