(This post is way overdue. Like 3 years overdue. But I think that a lot of what I learnt still remains relevant so here we go)
One thing I liked about my university was their hands-on approach. Instead of only lecture after lecture of boring theory, there were a lot of assignments where you had to build something and got a chance to work with many different technologies and areas of programming.
In our second year, we had what everyone agreed was one of the toughest projects in the entire course. In it, you had to build some kind of application and participate in Microsoft’s global coding competition called Imagine cup. Creating a team and working together on this project taught me a lot about what it means to be a team leader and manage a software project. It was also where, after dozens of pivots back and forth, the idea for this app was born.
Every day, millions of events take place. Some may be planned months in advance, the others just happen spontaneously. Maybe there is an event happening next door to you but you don’t know it. That is because there is no way to find events based on your exact location and time. In fact, even if there was important information that will also be useful to the people around you, you would have no way to share it with them unless you already had their contact. This is the problem our app would solve.
Initially called Lomio, we set out to create an a location based messaging app where users can post messages that can be seen by other users around them. One of the requirements of Imagine cup was that the project had to use Microsoft technology. Windows Phone was still a thing at the time, so if we were building a mobile app, it had to be for Windows Phone. We didn’t like the sound of that, so we turned to Xamarin, a cross platform development framework that would let us use one C# codebase for Windows Phone and Android.
In short (at least in my opinion), the end result of this project was not great. We didn’t get anywhere beyond the initial pitch for the idea in the competition, I had lost the team’s morale by being a tyrant and indecisive and the app neither looked or ran great. So when the underlying subject at the university ended, we thought it was the end.
But then a few months later, I suddenly found myself with some free time. I was applying for a visa to come to the Czech Republic that was taking much longer than I expected and I wanted to spend that time productively. I still cared about the idea and I was in a phase of my life where I felt that my life was too mundane and that there had to be more adventure and spontaneity, which, this app would enable. So I decided that I would build it on my own and wanting a fresh start, I called it Around.
When I went shopping for a whiteboard with my dad, I picked out the biggest one they had. I remember my dad asking, “Son, do you really need such a large whiteboard?” In the months that followed, he commented “OK, so even this one isn’t big enough” I sketched, wrote and squiggled for hours as I figured out the screens, user-flow, mechanics (a.k.a algorithms) and feature-set of the app. I had fallen victim to scope creep before where I kept adding features over and over again and I wanted to avoid it this time.
On the tech side of things, I still wanted to build a cross platform mobile app. But I didn’t like the development experience with Xamarin and C#. I figured there must be a better way and that is when I found the new kid on the block at the time, React Native. I liked its premise of taking Javascript and converting it into Native UI elements. It was a risky decision to use something new and unproven, but I liked it the best so I went ahead. By doing so, I learnt the technology (React) that served as the cornerstone of my career as it became the most popular frontend framework. On the server side of things, I used NodeJS before for Lomio and I liked working with it so I stuck with it.
The visa took 3.5 months to be approved and it was a horrible wait. But now I realise that it was also useful because it gave me the time to finish the app to what I deemed to be a “MVP” (minimum viable product). I ate, slept and coded for weeks on end until finally I published it the play store and triumphantly asked my friends to give it a try. I felt certain that it would catch on with some of them. But it didn’t.
Suddenly the visa was approved and I found myself in an entirely different situation to deal with so that marked the end of the project. Afterwards, it just became the thing that I would maybe-not-so-humble-brag at parties. (At least until this whole blog thing came out anyway.)
Lessons learnt
The hardest part about building an app is not building it. It is getting people to use it.
Sure, writing the code can be challenging. Especially when you are not familiar with the technology that you will be using. But if you are building an app, I assume you would want people to use it and that is where the real challenge lies.
You see, people are lazy. They need a strong reason to do anything or put another way, they either need a carrot or a stick. Either you solve a problem so great that it pales in comparison to the pain of going to an app store, waiting for it to download and signing up. Or you build something so exciting or fun that it is worth the pain. My app was neither.
One reason it was neither was due a factor that is inherent to any social network or platform that relies on user content. You need people on it for people to get on it. A social network with just one person is neither social nor a network. It’s a chicken and egg problem that is very hard to solve and can’t certainly be solved with code. It can only be solved with what makes most developers shudder. Marketing, promotion and talking to people. You got to think of out-of-the-box, one time solutions to get people to start using the app. You have to go all out to spread the word. While I had some ideas for promotions, I just couldn’t bring myself to do it because they were well outside my comfort zone and that is the one of the core reasons why it didn’t take off.
Creators’ blindness
Many creators fall in love with their idea. They think that it is the best thing ever and that there is no way that it can fail. If you are the only person who is going to use this creation, then that is fine. But if you want other people to use it, you need to see whether they will be willing to. As a developer, it’s easy to start thinking that code could solve every problem but perhaps that problem isn’t a problem after all or it can’t be solved using code alone. In other words, you have to validate the idea by showing it to as many people as possible and adjusting based on their feedback.
This is a soul crushing process. Your best idea, something that you were convinced was going to work could be proven otherwise by a single no. But that is the time to improvise, to come up with another idea and try again. None of the big platforms became what they are now from only their original idea. They evolved and grew over time.
While I knew about validation and “creators’ blindness”, I chose to overlook it. I didn’t want to be proven wrong because I didn’t know what I would do then so I trudged ahead. I didn’t want to accept that the idea was flawed early so I postponed it, hoping that the code will turn things around. Of course, it didn’t.
Avoiding scope creep is hard
Having fallen victim to scope creep before, I tried to be more careful. I told myself that I was only building a MVP (minimum viable product) with only the most important features. Except I wasn’t. The final app had a ton of features that no one realized was there. Offline support? You got it. Have no messages nearby and want to see another location? Sure. Don’t want to manually search for another location? Well, the top 3 common locations are now on the homepage. Push notifications? Yup All of these features didn’t matter at all because there was not enough users or activity in the first place for them to be useful.
It was only afterwards that I understood the true meaning of a MVP. A MVP is not complete, it is the smallest possible part you can build to prove the core concept. It can be hackish, it can be fake, as long as it can give a taste of what the end result would be like. If the core concept is not valid, then no amount of extra features is going to change that. After building and validating this core, you can start to build features based on the actual demands/complaints of the users rather than building features on a whim that are useless in practice.
Especially in a one man team, there are no external constraints and it’s easy to keep postponing the deadline over and over again. You have to make your peace with releasing an incomplete app, in order to let it evolve into what is truly needed.
Building an app is a continuous activity
Whilst working on the app I thought to myself “Well, once I finish all these features I am done!” While that might have been the case in the era where software was distributed on CDs or floppies, that is definitely not the case in the internet era.
The technology and the environment is constantly changing and you need to keep working on the app in order for it to survive. Moreover, since anyone else can build the same app as you, you have to constantly keep improving to stay ahead. That is the biggest reason why the current software giants have been able to stay relevant for such a long time. It is also impossible for test for the entire variety of devices out there, so there will always be device specific bugs that need to be fixed after releasing the app into the wild.
In my case, the app didn’t survive the new play store regulations that mandated all apps to have a privacy policy and got taken down. So much for a single release.
A project is the best way to learn a new programming language or framework
Before working on the app, I hadn’t written a single line of React. By the end of it, I felt comfortable using it for any new project and I also had several ideas on how to use it better. This is how I discovered that it is the best way to learn a technology. Not only do you have a larger goal to keep you motivated through the initial struggle of learning a new technology but you also learn how to solve several practical problems that inevitably arise whilst working on a project. (How to debug and fix bugs, how to make production builds, how to deploy web servers, etc..)
More importantly, the finished app was also something that I had to demonstrate my skills. I think it helped a lot especially since I was a junior programmer with almost no formal experience at the time.
Conclusion
As a result of my failed scope creep control, I also built a feature that let users report feedback within the app itself. But I never bothered to build a service to view that feedback. As I mentioned before, all successful software improve over time and true to that motto, Azure Storage has a web view now so after 4 years, I went back to take a look at that table.
I won’t lie, in the years after building this app I became a lot more skeptical of building apps on my own again. If I was going to be spending effort on building something, I wanted it to be a sure shot and so I never started working on a lot of the ideas I had. But I realise now that it is also an unrealistic extreme. There will never be a perfect idea.
So moving forward, I’m planning to use all the points I have outlined before to start playing around with new ideas. Before writing a single line of code, I will attempt to sell the concept first. If it doesn’t work, I will simply move on to the next idea and the one after that. If it still excites me and I can see myself using it, then I will build it for myself and maybe share it with the world (which is what I did with staticman-netlify-functions that went much better than I imagined). After all, that is why I do this in the first place, I love building and working with tech. As long as I get to do that on my own terms, I am happy.
