Essential Singapore Mobile App Buyer’s Guide
(5 votes, average: 5.00 out of 5, rated)
So you have an idea for a mobile app. You may be a startup looking to make the next Grab or Carousell, or you may be looking to enhance your business through a mobile app. Either way, making a Mobile App is certainly something that you should at least be considering, in view of the increasing mobile usage in Singapore and around the world. At RobustTechHouse, we have worked with many individuals and companies in similar situations. We often put ourselves in their shoes to think how best to confront the myriad questions that the entrepreneur or business may be facing. In fact, we have gone down the exact same path with our product: Savvee. In this Singapore Mobile App Buyers’ Guide, we answer step-by-step, honestly (we try to be unbiased) and comprehensively (as far as we can ! Please ask us other questions that we may not have answered) (warning: 4000 words ahead !) the key questions that you may be facing based on what we have learnt.
1) Native Mobile App or Mobile Optimized Web Site?
This is one of the first questions you want to ask yourself. There is a great infographic guide here. In our experience, the deciding factor is typically whether you need to use phone functions such as the camera, GPS, the microphone etc. If you do, a mobile app is the way to go. Also, in our experience, from a User Interface and User Experience (UI / UX) perspective, mobile optimized web sites tend to fall short of native mobile apps (i.e. people hate pinching), particularly if you are trying to extend an old website rather than build a completely new one.
2) iOS or Android or both or something more?
In Singapore, Android phones command about 51% market share and iPhones (which use the iOS operating system) command about 42% (source: Netmarketshare). So the common advice is to go for both iOS and Android (and forget others such as Windows and Blackberry) when developing your mobile app. The exception is if you are have a special use case and not intending to get the masses to download your app. For example, if you are going to provide your own devices to users or if you are targeting a very specific niche group of users (e.g. lower income users who may prefer Android phones).
Of course, this does not mean you need to develop on both platforms at the same time. It makes perfect sense to develop a minimum viable product on one platform, iterate on that with feedback from users and then develop for the second platform. The general rule is that less iterations = less cost, so perfecting what you need on one platform and then extending to the other is likely to save you some dough.
3) Native or Hybrid?
This is a topic subject to much debate but we are going to stick our neck out and simply recommend Native (at least for a large majority of cases, exceptions will apply of course). The developers of hybrid mobile app tools (and there are quite a few) will tout its advantages, the key ones being lower cost and faster time to market since you can develop on 2 platforms (iOS and Android) at once. And there are articles such as this which compare various factors you may consider in making this decision.
The reason we recommend Native is based on simple economics (and perhaps also some self-interest but let us explain). Given the number of hybrid tools available (and new ones keep popping up), only very specialized development houses will spend time and resources developing expertise in them. Development houses basically need to take a bet on which hybrid tool will be in demand. The support communities for each of these tools are vastly smaller than the iOS and Android development community so customization and future proofing is hard (we know iOS and Android operating systems will endure but cannot be sure about these hybrid systems). The result for the buyer is less choice (read: less supply of development houses = higher costs for you). From what we have seen, apps developed using hybrid tools also tend to be inferior from a UI / UX perspective because of the customization difficulty.
Once you have decided the platform and tools to develop your mobile app, it’s time to “spec it out”. In general, it is best to take time and effort to think through in detail what you want the app to do and the first step is Wireframing.
Wireframing is simply sketching out each mobile app screen as you imagine it to be. It can be a simple hand-drawn sketch (these actually work quite well if you don’t intend to do much iteration). If you want to collaborate with team members and iterate, there are several prototyping tools (most are freemium) that you can use including moqups, balsamiq, fluidui and invision. These tools allow you to create buttons and move through the app as you would when the actual app is ready, so they are great for visualizing the eventual app.
Wireframing also helps you think through details such as
- How will the user log in (if log in is required) — through facebook, google or by contributing a new email and password?
- Where would the mobile app get necessary data — will it be provided by the user or by the administrator through the backend, or linked from some data source?
- What phone functions does the app need — will it use the camera or GPS or microphone?
- What integrations does the app need — will it integrate with google maps, customer relationship management systems, data presentation software or in-house systems?
5) Designing, Graphics and UI / UX
Once you are happy with the wireframe, it is time to put the flesh on the bones. Typically, you will need a designer to perform this role. Most development houses in Singapore will be able to do this for you. Of course, you can choose to hire a freelance designer or even an in-house designer. Freelance designers are available from sites such as upwork and freelancer. Behance is also a nice site where you can go through the designers’ portfolio before making your choice. At 99designs, you get to run a contest and get many designs from which you can pick your favorite.
It is useful when briefing the designer to provide some examples of existing app designs that you like. Great app designers will help you by suggesting icons and app design conventions that you may not be too familiar with. Some will even tell you what is missing in your wireframe or suggest UI / UX tips. The latter are advantages of working with the development house to complete the design as they would be able to consider the mobile app from an overall perspective rather than just the design in isolation.
The design process is iterative and may take some time. Therefore, it is tempting to want to start actual coding in parallel with designing. This is not impossible, but you would want at least 80% — 90% of your design finalized before beginning coding. Iterations cost money so as far as possible, you would want to reduce coding iterations.
6) Technical Specification Analysis
Here is where a good development house really starts to earn its keep. While technical specification is the role of the development house (with the buyer commenting and approving), it pays also to take effort to understand the technical specifications prior to the start of coding. The reason, again, is to minimize coding iteration later on. A great development house will try its best to “fill in the blanks” for you while still sticking to your overall vision.
A key component of technical specifications is the entity relationship diagram (ERD). In essence the ERD will detail the database structure; that is, what data will be stored and how it will be organized (in database tables). Going through the ERD is a good way to identify missing pieces of a puzzle (e.g. “hang on, I need to capture the age of the user”). It typically also helps the team to go into the functionality of the mobile app in such depth that it gives rise to new questions and corner cases that your team may not have previously answered (e.g. “so how far away should the user be before I send him the notification?; should this be hardcoded or should I be able to change this parameter at the backend?”).
7) Technology Risks
At the time of technical specifications (or in fact earlier if possible), you would also need to figure out any Technology Risks of the mobile app. Technology Risks arise when your mobile app needs to utilize a technology that is not commonly deployed (e.g. machine vision, indoor positioning, natural language processing). At this point, the development house may need to embark on some research, either assessing whether it can build the technology from scratch or, more often, looking for a suitable software development kit (SDK) or application programming interface (API) that can do the job. Some SDKs and APIs are free, many are not.
8) Hire in-house or use an outsourced developer
We switch gears from the specification process to another key decision set that the mobile app buyer needs to make: Who will build the app? First question: should you hire in-house or outsource? Here are some points to consider.
- How well-resourced are you? Hiring in-house is a longer term commitment and in the Singapore context, a much more expensive option. If you are startup which has already raised rounds of funding (Congrats by the way!), then this could be a good option for you. The advantage of hiring in-house is that you will be in control of the process. You can easily cope with future iterations of your product. Your developer could be directly incentivized to create the best product for you. If you are not a well-resourced startup and would like to start with a minimum viable product, then outsourcing usually makes sense.
- Are you trying to build a mobile app development capability in-house? If you are an established business and your business is not mobile app development, you are likely not going to need full time development staff and they may became underutilized after the initial mobile app development and the mobile app enters maintenance mode.
- Development Risk. The idea of development risk (i.e. spending money on mobile app development only to realize after development that the product is not what you wanted) is going to come up repeatedly. Many believe hiring in-house will reduce development risk because your staff will have the same goals as you. This is not necessarily the case. To hire well, you do need to have a good technical recruitment process to find good development talent. On the other hand, development houses naturally mitigate this risk as they are likely to have refined their technical recruitment process (they know how to ask the right questions) and in time, should have weeded out underperformers (it is in their interest to do so). By having a decent number of development staff, the development house will also be able to mitigate against staff departures and handle advanced technical problems (there usually are senior developers around to help). But that gives rise to the next question: how to choose a reliable development house?
9) Choosing a Mobile App Development Company — Singapore or Overseas?
There are many mobile app development companies available to choose from (just google “Mobile App Development” or search on upwork or freelancer. There are also specialized mobile app development marketplaces such as AppIndex, ContractIQ and Clutch). To narrow down your choice, it is useful to decide whether you will insist on a “Singapore-based” developer or are comfortable with an overseas development company.
If you are comfortable with an overseas development company, you have a lot of choices from companies based in Eastern Europe to India and Vietnam. And given the choice, it is likely that you can get a lower quote than restricting yourself to “Singapore-based” developers. The trade-off for a lower cost is Development Risk. Some sites provide reviews and testimonials which help lower development risk. You can also research on previous work completed by the company and that may provide reassurance.
“Singapore-based” developers would in general have lower Development Risk. To be precise, the development company which you will sign the contract with should be registered in Singapore and be willing to sign a contract with jurisdiction in Singapore and under Singapore law. Legally, therefore, you will have a stronger contractual case against the developer should there be gross underperformance, not to mention reputational risk for the developer in the local context. There are other ways to lower your Development Risks such as tranched payment which we will discuss later.
Now to explain why I have written “Singapore-based” in inverted commas. Most “Singapore-based” development houses may have the actual developers based overseas (such as India or Vietnam). This makes the most economic sense. With a proper recruitment and staff management processes, these development houses should be able to attract and retain foreign developers with technical skills which are on par or even better than developers based in Singapore at a fraction of the cost. The beauty of coding is that it is a skill that can be learnt wherever you are in the world. Lower costs incurred by the development houses should eventually translate to a lower cost for the buyer.
Some buyers will still insist on developers based in Singapore. Clearly, this would mean a higher quote. But the more crucial question is whether this insistence will result in lower Development Risk. In our experience, we would say no. With the communication tools available today, you and the development house should be able to maintain good communication with the overseas developers. Technical capability and work ethic should not, in general, be inferior. Furthermore, if the development house has marketing, sales and project management capabilities in Singapore and is willing to be subject to Singapore contract law (so that you have easy and low cost recourse), that should further mitigate your Development Risk.
10) Choosing a Mobile App Development Company in Singapore — Factors to consider
So you have decided to go with a “Singapore-based” company. Now what factors should you consider in your choice, what questions should you ask?
- Cost: Clearly a consideration but not the be-all-and-end-all. It is equally, if not more important to pay attention to non-cost factors as discussed below.
- Specialization: Certain development houses have particular specializations even within mobile app development. For example, some focus on game creation. RobustTechHouse specializes in mobile commerce and financial technology. We readily admit that we are not very good at game creation, because it takes specialized game design and technical skills to create great games. If the development house has a blog, it may be good to check it out to understand where their interests lie. Also take note of the tone of the blog — is it self-promotional or are they genuinely interested in the subject matter?
- Portfolio, Reviews and Testimonials: Do look out for the past experience of the development house. They are a decent gauge for what you can expect to receive. Some development houses will go above and beyond “just development” and throw in (for free) quite a bit of consultation. You may be able to tell from the testimonials.
- Partnership model: Some development houses have standard quotation structures that they are reluctant to deviate from (e.g. only time and material quotes). Others may be more flexible and be willing to provide a fee cap. Certain development houses (such as RobustTechHouse) are willing to take equity as part payment, which could be a nice model for startups.
- Contract Terms: Look out for such terms as the payment terms (typically 15 days after invoicing, invoicing is likely done monthly as the project is being developed, third party costs (typically pass through, the buyer would pay directly for third party costs) and ownership of data and intellectual property (you would typically want to own the data and intellectual property and would want this clearly stated in the contract).
- Timeline: You may be in a rush and would like to launch quickly. Quotes which promise a quick turnaround may look tempting but don’t place too much weight on these. It is often tempting for development houses to promise quick work in order to win the contract, but the truth is that it is very difficult to provide an estimate of the overall development process early on, especially without full specifications.
- Is the development house interested in the success of your mobile app? This question, although very important, is not easy to consider objectively. There are tell-tale signs though, such as — How responsive is the development house during pre-sales? Do they take time to understand your business? Do they provide value added suggestions and ways for you to reduce cost or optimize your approach? Do they take a robust and long-term view of the technical needs of the project? Is the development house willing to help out in small ways even before signing on the dotted line (help could include simple things like email setup to making useful introductions or links to interesting industry resources)?
- Are you dealing with a decision maker or sales person? As discussed throughout this article, the nature of mobile app development is fluid and particularly in post development, you would like a development house to be able to exercise some flexibility in helping you, rather than sticking to the letter of the contract. You don’t want to hear “sorry, all my developers are deployed elsewhere, your development period is over and your bug fix has got to wait for 2 months”. Dealing with the decision maker directly helps you assess if the development house will exercise flexibility down the line and indeed if he/she would allow such flexibility to be exercised quickly.
- Technical Ability. Ask for the CV(s) of the actual developer(s) that will be assigned to your project to have a sense of his / her experience and technical ability.
11) Quotes and service models
As much as we would like that buyers only consider RobustTechHouse, we cannot in good conscience recommend that you only obtain 1 quote. Obtain at least 2 quotes from reputable vendors, more if you have the time, for comparison.
In general, there are 4 partnership models available in Singapore.
- Time and Material quotes. Here development houses will quote on a per manday basis (in Singapore, this could range from S$250 to S$800 per manday). The development house should concurrently also provide an estimate of the total number of mandays that it would need to complete the project. Be aware that this is only an estimate, not a cap — so the final bill could exceed the estimate. When under a time and material arrangement, it is crucial to keep track of the amount of time (and hence the fee) that the development house has accumulated. The development house should keep you updated and also alert you as you are approaching the original estimated price.
Development houses prefer time and material quotes as it mitigates the Specification Creep risk for them. Under a time and material arrangement, buyers tend to be more circumspect about specification changes because time extensions mean more costs ! In a way, it is also fair to the development house as their costs are largely also time-based.
The estimated time chart should breakdown each resource that is needed which may typically include iOS developers, Android developers, backend developers and a project manager. As an option, you can also have a dedicated tester included in the estimated time chart.
- Capped quotes: To make sure you keep within your budget, you may want to request a cap on the quote. Development houses are generally willing to consider this only if you are very clear in your specifications upfront. Significant changes to specifications may result in post-hoc changes in the cap. As to what is considered a significant change, this is generally a negotiated outcome (read: another reason to get an appreciation of the flexibility of the development house upfront).
- Fixed price quotes: Very similar to capped quotes, with the only difference that there is no chance that you will be charged less than the fixed price. Therefore, fixed prices should be lower than what would otherwise be the cap. Again, it pays to have the specifications spelt out in detail before obtaining the quote, otherwise development houses may mitigate their Specification Creep risk by providing higher quotes.
- Part equity payment: A few development houses will also be a technology partner in the true sense of the phrase. Particularly for startups, mobile app development is an ongoing process (e.g. how many iterations has Grab undergone?). If you want someone on your side investigating latest technologies and suggesting new builds and features on an on-going basis, this is a good model. In this model, the development house will function much like a CTO. They will be interested in not only your mobile app idea but also your overall business plan since they are sharing execution risk with you.
12) Agile development
The trend in software development has decisively moved towards agile development. In simple terms, this means that buyers should expect the developer to provide interim builds. Agile development reduces Development Risk for the buyer because you can tangibly monitor progress. However, buyers need to be prepared to test and provide feedback on unfinished products. For some not used to this process, it may come as a surprise (“hey, how come you are sending me something which doesn’t work? Are you shabby or a bad developer? Aren’t you supposed to test things rigorously before sending it to me?”).
It is usually in the interest of the buyer to ask for agile development and interim tests. We have come across many horror stories where the buyer waits for several months and then receives something not workable. Having lost valuable time, the buyer then turns to other developers to “continue” the development, only to find that the old code is not useable. In general, it is not easy to “continue” code development, particularly if the old code is badly written and documented. In order to provide a robust outcome, many developers will simply prefer to start from scratch rather than fix someone else’s mess.
13) UAT and Handover
The agile development process places less emphasis on the final User Acceptance Test (UAT). Nonetheless, it is good practice for the buyer to go through one final comprehensive test of the mobile app before signing off on it. In going through the UAT, it helps to have a checklist of all test procedures. Test both the front end and backend simultaneously. Corner cases should be tested to identify bugs.
Once done, the mobile app can be officially handed over to the buyer. This may mean deleting test data and the changing of admin passwords for security purposes to prevent developers from accessing production data. However, in practice, you would still want to allow select developers to have access to the new passwords for quick bug fix and maintenance purposes.
14) Launching the Mobile App
Before the app is ready, you likely want to have a plan to launch the mobile app. The development house should make sure they successfully list it on Google Play and the App Store. Listing on Google Play is pretty much instantaneous but listing on the App Store may take a week or so, depending on how quickly Apple reviews the App and whether the app complies with the Apple App Store rules. There are many reasons for possible rejections, which will add to the timeline. An experienced iOS developer will generally be able to avoid most of these issues.
Beyond simply listing on the app stores, you may need to consider marketing activities to attract mobile app downloads. This may involve submitting to Android app review sites and iOS app review sites. You may also consider app marketing activities. App marketing is generally beyond the purview of mobile app development houses but they may be able to help with some recommendations of reputable digital marketing agencies in Singapore.
15) Maintenance and Post Development Considerations
It is prudent to ask the development house about available maintenance plans early on, but you may not want to sign on the dotted line until you are comfortable with the development house.
Post development, you will want the development house to remain very responsive especially if you have questions or encounter bugs, or even worse, crashes. You will want them to fix these issues as quickly as possible or it may mean lost business to you. Providing good service post development is often what distinguishes a great development house from a not-so-good one. Find development houses who would genuinely want your mobile app to be a success.
16) Hosting Considerations
Unless you are large organization with your own servers or where security is an extreme concern, your mobile app is going to be hosted on the cloud. There are many cloud hosting services around, and the 2 key considerations are cost and scalability. Our favorite solutions which provide pay as you use solutions (reasonable costs when you have low number of users, and easily scalable if you achieve strong traction) are amazon web services and digital ocean. These offer great server management tools and we are able to be informed immediately if and when server-side issues arise and fix them.
17) Data Protection Considerations
For companies in Singapore, since the introduction of the Personal Data Protection Act in 2012, the protection of personal data has been an important consideration when developing mobile apps or website which might collect such data.
We just published a separate blog article on this, which draws guidance from recent decisions by the Personal Data Protection Commission. Rather than going through vague legal jargon or non-specific advise by consultants, we feel examining actual decisions are a better way figure out what steps are needed to comply with the PDPA.
Well, we hoped the above helped ! Feel free to chat with us for further questions or leave comments below. We will be adding more details to this article as we go along so check back sometimes. In the meantime, hope you enjoyed our Singapore Mobile App Buyers’ Guide. All the best with your mobile app development !
Brought to you by the RobustTechHouse team.
Originally published at RobustTechHouse — Mobile App Development Singapore.