Mingly - My First Real App

In 2014 I was 25 years old and a newly minted programmer with approximately 12 months of programming experience. Having recently switched career path from Economics to Software Development, I had just started a graduate job in a big Scandinavian bank working as a software developer in the Capital Markets IT department.

Sefkan, a former colleague I had worked with briefly as juniors at a management consulting firm, had just spent a year studying in New York, living the metropolitan life first-hand in The Big Apple. I remember him being so incredibly excited about New York’s social scene and amazed at how normal it was to meet new friends in bars and restaurants, seemingly just striking up conversations with strangers about interesting topics.

Having recently moved back to Copenhagen, Denmark, where we were both living, he was still high on his trip and wanted to bring that same big-city “buzz” and networking experience back to Copenhagen. Back then, Google wasn’t evil, Facebook was all the rage and everyone and their mother was on Tinder. So obviously, to a group of 20-somethings the way to connect people was through an app. Provide a platform where people can meet other, like-minded people over a drink and boom! Copenhagen would instantly feel like downtown Manhattan. I was ready to get my hands dirty at building the next global social network, and I remember Sefkan’s excitement about the project being so contagious, that for a while I was convinced that Copenhagen was going feature in the next big Hollywood rom-com.

We spent a few evenings and weekends sketching out solutions over drinks, and shortly after we got started we met another developer, Christian, who had previous experience developing iOS apps and who liked the idea. We got him involved as well (we are actually still business partners today), and we were ready to solve the biggest social problem since Tinder made online dating cool.

Then we got to work. We probably spent 1-2 months of our after-work hours brainstorming design, creating mock ups and developing a prototype for the app that we could show friends and family. In hindsight I don’t think this was a bad approach to product development, but

a) We realized too late that it wasn’t necessarily a problem best solved by technology.

b) We definitely did not spend nearly enough time researching existing solutions that might work as a prototype for us.

c) You never get honest feedback from friends and family - they’ll pretty much always tell you it’s good (see The Mom Test).

Lesson: Be very clear about the problem you are trying to solve and validate before you do anything else. Is it actually a problem that people care enough about solving? What ways are people solving it now? Can you find a group of people for whom this is really a problem?

The main premise of the app became a cross-breed between Meetup and Yelp, where users could create ad hoc group events and discover bars nearby. Initial reception was fairly positive and we received lots of nice compliments on our interactive prototype. But as I just mentioned, we mainly showed it to our friends and family and I think we probably fell into every single trap mentioned in The Mom Test. In hindsight, there wasn’t a big demand for an app like ours once we started talking to people outside our closest social circles.

After our initial luke-warm feedback sessions, we weren’t quite sure what to do next. We convinced ourselves that part of our problem was that it was “too much of a prototype” and the lack of fully fledged features meant that people weren’t seeing the full vision. If we just invested a bit more time in building out the app it would surely be a success. Since it was currently trying two solve to problems at once (event creation and venue discovery), we decided to first focus on honing one of them. Venue discovery seemed like the easier problem to solve at the time, so we decided to focus the app on discovering bars nearby and viewing their offerings.

Lesson: When building a prototype, make sure it clearly demonstrates how it solve your problem. If the prototype doesn’t solve the problem, building it out with extra bells and whistles won’t either.

After another month or so of development, we had removed the event planning part of the code and had a functioning MVP where users could view a list of bars nearby as well as a brief overview of their opening hours, price range and offerings.

We quickly realized we had created niche version of Yelp that, at the time, only worked in Copenhagen. Did this even make sense?

Not willing to realize our sunk-cost in developing this app that we still hadn’t realized that nobody really needed, we decided to pivot it into something that at least we wanted. Christian had mentioned that he could never figure out which bars around had Happy Hour on, so maybe we should focus on providing this service to people. We decided to invest a bit more time into it and turn it into an app for discovering local Happy Hour deals. Somewhat far from the original vision, at least this was a clear problem with an obvious solution. And who knew, maybe there were others like Christian out there looking for their next 2-for-1 drink?

Lesson: Figure out the value proposition to your solution before you invest time in developing it. What sets your product apart and why should users change their current solution?

It was a big day when we launched in the App Store. I remember it being very close to Christmas, so we were super excited to see all the downloads roll in over the holidays, when everyone would be going out to celebrate and lots of places were putting up holiday deals. Slowly the downloads ticked in: 1, 2, 5, 10, 13… We probably got around 100 downloads over the 2 week Christmas period, and then it flatlined.

It was an underwhelming launch compared to our expectations, but I think that most developers experience this. Everyone thinks their app is going to skyrocket to the Top 10 overnight. I don’t recall the exact numbers, but I think got about 400 downloads over a period of 3 months. And that required a lot of promoting! We pitched it to each and everyone we knew, tried marketing it on social media and to students and backpackers, but we had quickly diminishing marginal returns.

Lesson: Launching an instant viral hit is like winning the lottery and most hits are actually the result of tremendous amounts of hard work and luck. “Build it and they will come” is an illusion and you should expect your first version to flop.

Around 4 months after we launched Mingly, we still hadn’t made much progress. Downloads had completely stagnated, we had 5-10 weekly users and no idea how to turn it into a success. We could invest more time in developing cooler features, but by then we had partially realized our sunk-cost and weren’t really that keen on spending more time on it unless there was a clear pay-off: a large surge in users to boost our morale or a way to finance additional work on the project.

In April 2015 we decided to cut development. The team had slowly started to move onto other things and some of us were getting busy with other work, so we shut down the servers, company and the project. It had been a fun and exciting process, but after 10 months of work we threw in the towel and realized our first startup failure.

Lesson: When starting a company, make sure to sketch out the roles and responsibilities from the start so they aren’t grounds for disagreements later on. This is especially important if it’s a collaborative side-project, because they usually don’t have first priority for everyone and it can be hard to keep the team focused.

On the plus side, here are some of my good take-aways from starting (and closing) Mingly:

1. It was my first end-to-end deployment of an app to the App Store. Usually side-projects just fade and end up in the graveyard of started-but-never-finished projects, but we made it all the way to release and even tried marketing it for a few months.

2. We developed something that we ourselves wanted to use, which is always a good start because then you are the user! Unfortunately, it just didn’t end up being a big enough problem for anyone (including ourselves), so we ended up losing interest.

3. We had sufficiently orthogonal skill sets* in the team and got along really well. We are all good friends today and Christian and I later ended up doing 2 new projects together, one of them being our current startup Ante.

*By orthogonal skill sets, I mean that we had different skillsets / comparative advantages (like sales, design, development), instead of all being e.g. really good backend developers.