15 things you should know before developing a mobile?app

The worst that could happen to a mobile application is a lack of users. Several mistakes can lead to such a scenario at every stage of development. The list of pitfalls to avoid during mobile software development is presented by Jurijs Meitalovs, Head of IT at fintech platform Bilderlings.

1. Goal?setting

Sometimes management wants “like the competitors have”, forgetting that your users might need something different. Or the task might be defined based on the manager’s personal preferences?—?where they end up liking the product, but for the actual customers it is not appropriate. Therefore, the first step should always be user research?—?studying the specific needs of the clients. And only then you should write the technical specifications based on this study.

If the specifications are written without any research grounded on specific customer needs, finding out the root of the problem later on will be extremely difficult. Then your application will be barely used, and you will have to guess what is at fault: the technology, your IT staff or your UX designers.

2. Planning and?Testing

Launching an application involves several stages: preparation and planning of the design, working through the customer experience (details below), development and initial testing of the application by the development team, followed by internal and external testing with a group of loyal customers, and only then going live. Of course, each case is unique, and user testing can be skipped, but this might lead to missing some obvious bugs and flaws in user scenarios, as the development team can become too familiar with the work and miss obvious issues.

At every stage, it is necessary to gather data and feedback, fix errors, and take user comments into account.

Also, at the feature launch level, it’s possible to split the functionality into several groups of specific users to test (analogous to closed testing). Sometimes it’s also useful to perform A/B testing: testing a feature on different customer groups to understand what works better and what is worse, and then choose the final version of a particular feature.

Additionally, developers can run the application on emulators to check how the app looks on various devices, with different resolutions, without having them physically. Or, one can use built-in testing tools in app stores. For example, Google allows you to run tests on a multitude of devices and, for instance, check how the application looks and works on different devices and with various screen resolutions without needing to have all these devices available. There are also third-party services that offer something similar.

3. Design

Design is not merely a task that can be delegated to a designer while others rest. It’s a collaborative effort involving IT, business representatives, users, and entails meticulous planning of the customer journey, studying user experience, and reassessing everything you’ve developed. This process doesn’t end with the application’s release.

4. Excessive customisation

Chinese application WeChat is an app for everything. It is so overloaded that finding the right option takes ages. The other extreme is to create a separate application for each task from one service provider. For example, if I want to use an online bank both as a legal entity and as a private individual, I do not expect to have to keep two different apps on every device. The right way to go here is to find a balance between the two extremes.

5. Functionality problems

There are two frequent problems?—?too many features or too few features of an app. Having too many features is also a bad idea. The mobile application should be able to do basic things. Integrating everything in an app will make navigation too complicated?—?a UI that works in a desktop browser can be terrible for someone using their smartphone. Therefore, you should know exactly what the client needs, and focus on that. This is where UX design comes in.

6. Implementation: native VS cross-platform

There are app development technologies that are compatible with all systems, and those that are natively designed for each specific operating system. In the former case, a single code base should support both Android and iOS devices. In the latter, development and maintenance costs are nearly doubled. However, having the same code work across different platforms runs into the question of selecting the right cross-platform tool to use?—?a decision that will be guided by the tasks your service has to perform.

Many new frameworks and cross-platform developments can die out quickly. You should keep track of how a particular technology is growing and developing with the times.

7. Contracting or in-house development

Doing things by yourselves or outsourcing a project is a matter of resources. In-house development takes some careful allocation of resources. Then again, selecting an outside company is always a lottery?—?you never know how things will go. You might find a great contractor with some spectacular projects in their portfolio, but then have an unprofessional developer assigned to your development?—?turning your dream into a quagmire. A combination of factors is important: the professionalism and experience of your outsourcing company, the professionalism and experience of specific employees doing the work, and your own ability to monitor and guide the development progress.

8. Communication among?teams

The ideal option is a team-to-team relationship. Something to note here is the cost analysis and reconciliation of assessments on both sides. It is important that you assess your own technical readiness adequately?—?are you ready to do your part (the same API or some new functionality) to integrate the new software?

9. Security

We work with financial data, which makes security a priority from the start. Integration always begins with a software audit?—?we cannot rely on the good faith of the developers; professional penetration testers must verify their work first. Our applications must include certain technological solutions to protect them from malicious codes and data leakage. This is a must have?—?you are responsible for verifying the security of your product.

There are guidelines to help you with this, such as the OWASP MASVS, which is, in fact, a list of widespread vulnerabilities to avoid or eliminate in your development. Each vulnerability is easy to prevent as long as the developer is aware of it, but it’s too easy to overlook some of them as you go along. So always discuss everything at first, and always solicit an independent penetration test before the release day.

10. Store?review

Once your app is ready, it must be uploaded to the store and submitted for review. Android’s Play Store does this automatically, while in the iOS App Store it is done manually?—?a specific person-reviewer downloads your app and checks its performance for compliance with iOS requirements. Any violations or dubious moments will require further development before the app is released. Each such cycle takes at least a full day. So always prepare everything in advance to avoid unnecessary delays.

11. Feedback

First, you should monitor the reviews that customers leave on the App Store and on Google Play. If you refuse to respond and make changes, your rating will worsen?—?dissatisfied clients mean scathing comments and spoiled first Impressions. Second, you may want to think of an alternative feedback channel: provide a phone number or support button in the app itself, preferably in plain view. If the client does not know where to go with the problem they are having, they will likely complain about it in the application reviews.

12. Activity monitoring

If you have 100,000 clients and just ten downloads, start looking for where the problem is. Perhaps your app has been downloaded a lot but is not really used. Clients just open it once and never come back. What could be the reason? User behaviour analytics can help you find the problem out. Find a way to analyse the data accurately and draw the right conclusions. This is something that needs to be considered at the start?—?so set the task and assign somebody to it early on.

It’s necessary to collect and definitely analyze the application metrics. These include technical errors, performance speed on different devices, etc., and most importantly, usage metrics: what clients use, what their customer journey funnel looks like, and so on. This is the foundation that helps us understand: what we can improve, which functionality to move, and what to remove entirely. Nowadays, there are many services that collect analytics data for you. It’s possible (and necessary) to use services for data collection and analytics, ranging from the basic Firebase and Google Analytics to advanced ones (e.g., Smartlook).

It’s crucial to collect and analyze application metrics. These include technical errors, performance speeds on different devices, etc., but most importantly, usage metrics: what customers are using, the funnel of their customer journey, and so forth. This data foundation helps to understand what we can improve, which functionality to relocate, or what to remove entirely. It’s possible (and necessary) to use data collection and analytics services, ranging from the basic Firebase and Google Analytics to more advanced ones (e.g., Smartlook).

13. Go-Live. What’s?Next?

An application won’t sell or download itself, and marketing campaigns should be thought through from the start?—?how exactly you will promote and popularize it in general. This is a separate, systematic job that requires a strategic approach, not just posting on social media twice.

A lot depends on whether the application is the main product or an addition to the main one. There’s no one-size-fits-all approach?—?marketing efforts and overall promotion depend on the goals and capabilities of the company. But many promotion rules are similar to web services?—?for applications, you can also use SEO to increase visibility in app store searches?—?ASO. This should be a systematic effort within the context of the company’s comprehensive marketing plan.

Additionally, the product must evolve, enhance its functionality, improve customer experience, etc., and all this requires a budget. The work on the application does not end with the go-live event.

Even if the product is not developing, it’s necessary to update SDK versions and supported operating systems, which are constantly being improved, or to consider new features that appear on devices and can be used by you.

From this perspective, with the application’s release, the work on it essentially just begins and will require no less effort and energy than developing it in the first place.

14. Marketing

The application won’t sell or download itself, and marketing campaigns should be thought through from the start?—?precisely how you will promote and popularize it overall. This is a separate, methodical task that requires a strategic approach, not just a couple of posts on social media.

15. Funding

You’ve launched the app: what next? The product must evolve, expand its functionality, improve customer experience, etc., and all this requires a budget. The work on the app doesn’t end with the go-live event.

Even if the product isn’t actively being developed, it’s necessary to update SDK versions that are continuously improving, or to incorporate new features that appear on devices and can be utilized by you.

If you’re using third-party services to offer additional services, they too require support (and money).