A startup-ish project that never ships

It feels like ages, but I left this project just about one year ago. I call it “startup-ish” because we set off to solve a big problem by building a product that never existed before. However, as opposed to normal startups that are either bootstrapped or externally funded, this venture had seemly unlimited funding from its parent cooperation, which I consider to be the number one reason for project semi-failure.

This article may sound like me bitching, again. Anyway, here’s what I think that killed the project:

1. Unlimited resources, no clear goals
This project never had a sense of urgency, we never wanted to build a MVP, because we never had time or money issues.

We were doing Agile, but iterations after iterations, we didn’t know where this project was heading towards. While many young startups strive to launch new products over a weekend, we kept adding nice-to-have features and pivoted once in a while without a clear go-to-market timetable. No one knew exactly what we were trying to build, even the fonder himself I guess. New features kept coming in, because the fonder just got new inspirations after talked to someone. Project plan got shifted because the fonder had an important demo in an upcoming media event.

When I was there, we changed 3 visual designers, each has his/her own unique taste of fonts and colours, so we ended up re-skinning our product 3 times, 3 times. We even re-branded our product, by paying some consulting company.

2. Unwise mobile strategy
Imagine your web developers had been smashing the code so hard in the past 3 months, and as the fonder, you walked up the podium, announced the website to a large group of audience. Imagine the eager audience immediately pulled out their smart phones and started to browse the your website. How nice would it be, if your website could work on the phones as nicely as on the desktops, if.

As the only mobile app developer in the team, working with 4-5 web guys, I was trying very hard to provide the same feature set as the website did. Then I realised I just couldn’t keep up the same speed.

Then I started wondering why we allocated so many resources in building the website, while our first batch of users were going to experience our product on their phones, then only to find it totally unusable. So what’s the point of prioritising website development over app development in first place?

Watching the front-end contract developer cursed while trying to fix responsiveness issues happened on various mobile devices and various browsers, I was also wondering, was it worth it? Maybe we didn’t even need a native mobile app given we had a functioning responsive website.

3. Developers caring too much about techs
The web stack was once like: Ruby on Rails as backend feeding APIs to both iOS app and web app, the web front-end used a javascript framework called Maria.

Later on, after some contractors jumped onboard, the web team decided to rewrite the web app following traditional Ruby on Rails paradigm. The No. 1 reason for this, as far as I can recall, was that writing unit test for Maria was painful. The web app stopped using the same set of APIs which was used by iOS client.

Later on, to handle some tricky font-end UI requirements I suppose, the contracting consultants decided to introduce AngularJS, which again is a web client needs to talk to some APIs. This time, the web team decided to create a mini-set of APIs just for web app.

Later on, someone started talking about re-writing the iOS client in Swift because “it is the future”.

Ending: after nearly two years of working on this project, I finally walked away and never looked back. As far as I know, this project is still under development, the iOS app hasn’t been shipped yet. I wish this project the best of luck.