So you have a great idea for an app. Now, how to build it on a budget.

With the startup buzz going around, almost everyone is thinking of the next million dollar idea. Come on, who wouldn’t want to be the next Mark Zuckerberg. I was one of those dreamers, quite obviously. I found that there is not a lot of information available on how does one go about building an app in reality. Who do you need to engage, the costs, the process. So for the benefit for non technical aspiring entrepreneurs, I’m going to share how I did it and how much it took.

A little bit of background, I came up with the idea of a social feedback app for the workplace, and I got it built and launched 1 year later whilst working part-time in a day job. I have a background in computer science, which obviously helped in reducing the cost. I will explain them in detail later and what is the monetary impact. The numbers provided are just based on my knowledge and experience, it varies a lot based on country and what your expectations of the vendor.

Before we start, let me share a little bit about how tech development works. First of all, time is money. Everyone you approach to engage, charges you based on time. So it doesn’t take a genius to figure out that the less time you require from them, the cheaper it will be for you. Currently, in software or product development, you would hear a lot of stuff about agile development. Where you basically have user stories ( think “I will like to be able to sig up on this app”) which get built in sprints (around 1–2 weeks depending). This would work well if you had an in-house team, or did not know what you want to build up-front. But it would cost more and it would be hard to control the timeline ( I am guessing you can’t wait to launch right? ). Also, in agile development, the ideal team is one that compromises of the designer, mobile and back-end developer. To save money I did not engage an agency that would be able to provide such a set-up as they quoted me upwards from S$60k which was not what I was willing to part with. To save costs, I engaged separate vendors for each part of the puzzle that needed to be built and I coordinated and project managed the entire thing. This sort of project management would be classified as the traditional a.k.a waterfall methodology.

1. Business requirements

Before you can approach anyone for a quote, they would need a business requirements document from you. Because just by saying “I would like an app that allows people to give each other feedback” is practically useless. You will need to document down every functionality your app would have. Including details like do you allow users to login using their social media accounts, how would users be able to reset their password etc. You could engage someone to sit down to understand what you want and write this for you, again this would be more cost to you. So save yourself some money and get down to it!

Things to note:

  • keep it focused
  • try to keep number of features down to a minimum
  • don’t forget all the boring stuff like user management ( login, edit profile etc)

What I did not do well:

I was worried that if the app just allowed users to give each other feedback, it would be not able to attract users to keep going back to it. So I added features and functionality that had nothing to do with giving feedback, like group chat and a cool radar looking like screen that showed who was nearby. This made the app more confusing and less focused, feedback from users afterwards was that it was not clear what this app was about. So I quickly removed whatever I can soon after launch. Remember that time is money, if I had not included those features in the beginning, I could have reduced the cost by some and launched earlier.

2. UI/UX design

I am a person who knows my strengths and weaknesses. I can code, and I can draw for fun. However, if I wanted a professional looking app I would need to get a pro to do it. I searched online and on dribbble for mobile app designs. I was looking for flat designs with a bit of depth and found a designer, Mike Hince ( Bossanova ), whose style was similar to what I was looking for. I would advise that you find a designer whose style you liked, instead of getting a random one and trying to make them conform to your inclinations. It’s much happier and less painful this way. :)

I provided Mike with the business requirements document, and from there he was able to provide me with a quote and timeline.

Communication tools:

  • Invision
    Invision basically allows you to play with the design that the designer has come up with, by adding clickable hotspots ( areas ) to images. So you can map out what should happen when you tap on an arrow etc and go through the app to ensure that nothing is missed out.
  • Trello ( I moved to Meistertask now )
    Whilst you can add comments to screens in Invision, what you are unable to track are screens or things that have not been done yet. I’d suggest only doing this at the later half of the process, let the designer first start mapping how the design and flow of the app. Then you will have a better idea what else you will need.

What I did not do well:

I was mainly just focusing on whether I liked the overall design of the app, as usual, the devil is in the details. I did not pay much attention or spend much time on the copy writing ( the text that appears ) and the little things like functionalities that affected development but were not mocked up. These later resulted in me having to keep changing the texts or fill in gaps that I did not catch.

3. Mobile app development

Now that you have the Invision project with all the mockups, it’s time to make it into a real app. To do so, I usually just shared the Invision project and business requirement document with mobile app developers to get a quote.

Native or non-native?

I am assuming that you are looking to develop the app for both iOS and Android like me. A common question mobile app developers will ask you right at the beginning is whether you are looking for native or non-native apps. In a nutshell, native apps are developed using iOS and Android’s own development environment and language. That also means that you essentially have to build two apps. Non-native or hybrid apps are built using frameworks with the idea of only having to code the app once and it would run on both platforms. Sounds like a no-brainer? Not really, as there are always trade offs in adding additional layers to anything.

One year ago, I decided to play it safe and went native. As I was not sure which way the hybrid frameworks would go, which would drop out and lose support etc. I engaged a local Singaporean wanting to be able to sit on the guy should anything go wrong, however, he ended up engaging a Ukrainian to do the work. I felt that such information should have been presented upfront to me, as I knew the impacts of having to deal with someone offshore. It is much harder to communicate, you would have to give really detailed instructions and that would also mean that you worked two shifts as now you had to be on-line and responding when it was working hours in Ukraine.

What I did not do well:

I made what I felt was the best decision at that point of time. However, as I am writing this article right now, we are rewriting the app in react native ( a framework by Facebook ). What made me do this? Couple of reasons. Which I shall explain so that you may make educated decisions based on your needs.

  1. Cost
    Every time I wanted to change something to the app, I’d have to do it twice for the native apps. So double the cost each time.
  2. Time savings in testing
    Since the same thing had to be done twice, everything had to be tested twice, and there are double the number of ways the developer could have done it wrong ( yes, who would have thought… ). You will still need to test both apps, but if there was a non platform specific bug, chances are you would only have to get it fixed once and it would be fixed on both apps.
  3. Better quality developer
    I guess it is apparent by now that I am not impressed at the quality of the app developer, the lack of attention to details and testing prior to marking something as done. I had to jump a few times to explicitly get them to implement things like caching to increase the performance of the app. Things that I assumed an experienced app developer would do automatically. So in the selection of the app developer to rewrite our app in react native, we are now a lot more careful and know what kind of questions to ask to better assess their experience and knowledge.
  4. Our app should work fine with react native
    As we are not building a game, or something that uses a lot of the phone’s capabilities, the risk or impact of using a hybrid framework is low. The hardest things would probably be assessing the camera and phone book, which have been done many times over by other developers.

4. Backend development

When you build a mobile app, there is always a server driving it in the back. Things like user log-in and any data that you would like to store and process, are all done by the server. The server is the heart of your business and contains most of the business logic. This is where I am adamant about not outsourcing. I built all the server API calls myself, saving myself about S$10k to S$20k. But it’s not entirely a money issue, I feel strongly that you should never outsource the most important part of your business. Today, I have gotten a very competent in-house developer to port my server from Python Flask to Django. Again, I cannot stress how much difference it makes having someone sit next to you versus a thousand miles away, despite the current trend of outsourcing dev work overseas.

5. Testing

This section could be written as part of the development phases, but it is such a time consuming and important phase that I think it warrants a section of it’s own. No matter who you engage to develop anything, you will have to test it yourself. Why? Because:

  1. Nobody cares about it as much as you
  2. Nobody cares about it as much as you (repeat x 100 )
  3. All vendors will require you to sign off and accept the work done, you can’t do it if you haven’t tested it

Testing is something that you would be spending most of your time doing. Over and over again, flagging bugs on Trello, testing them again afterwards to ensure that it was fixed correctly ( major sigh ), repeat until it is fixed perfectly. Some of you would think, surely the developer is supposed to test it. The answer to this is yes and no. As a developer myself, I know that it is impossible to cover all possible edge cases and exceptions. However, there is also a expected minimum level of functionality and quality to be expected. Example, when the developer says something is done. I update the app, open it up and it crashes. Such things make me want to tear my hair out and murder someone. I cannot complain too much, as I did not engage an agency that charges a premium. When you go with the cheaper option, you kind of have to accept that you will not get the kind of quality and response you would expect from a professional, and have to do the micro managing yourself. Also, by the time you had something workable to test, and find out that your developer is not as good as you would like him to be, you are so invested in terms of lost time that you just have to stick to it and see it through to the end no matter how painful the journey is.

6. Miscellaneous costs and App Store

I’m sure these information are freely available everywhere, but for completeness, I want to highlight that you would need to purchase two membership plans. One for each App Store to be able to publish the apps under your company’s name. For iOS, every update to the app requires Apple to review and approve. This takes about 3–4 days on average based on my experience. For Android, this is not necessary. So you can just push to production immediately and wait for the App Store update.

Ending thoughts

All in all, just to develop the first version of Hoorah, I’ve spent S$36k ( an extra $1k for AWS and software licenses etc ). Remember that if you have to get someone to develop your backend server for you as well, you would have to budget a little more for it.

It was a year long journey from concept to launch, I was coding my APIs with my newborn baby nursing on my lap with one hand. I am very proud that I managed to pull it off at the end, but you know what. This feat is just the beginning. Showing a user a clickable mockup vs a working app is very different. I’m not a huge believer of the lean startup concept, sorry. The feedback I got after being able to get friends and family to download and the app were so different from when I showed them a clickable mockup. Even before our first pilot started, I had gotten so much feedback and ideas from people I’ve shown it to, that we were already planning and designing version 2 of Hoorah. Do not ever think that launching the product is the end of product development. It is only the beginning to a lifetime of refining your product, not to mention building a business.

We are hoping to launch version 2 of the mobile app and migrate to our version 2 by early May, and I am so excited! It will be so cool! Social feeds, customisable corporate values and hash tagging of people. Anyone else is having difficulties trying to figure who in your organisation has a specific skill? Search for the hash tag! Simple yet may be the best solution yet to an age old problem!
Elisa Ang is a huge geek who loves to code, machine learning and designing solutions that combine the two to solve problems. On top of that, she has a huge obsession with make-up and productivity methods. An idealist and a dreamer, she built Hoorah hoping that people in the workplace would be nicer and more helpful to one another.
If you will like to know more about Hoorah or try it out in your department / team / organisation, drop me a note at elisa.ang@hoorah.io.