There are two important questions every entrepreneur asks. The first one is, "Does the market need my idea?". If the answer is "yes," they move on to the second — "How much will it cost me?". In this article, we're helping you understand how to estimate time frames for your app development and, consequently, calculate the development cost.

Does your project need an R&D phase?

R&D stands for research and development, a set of activities that includes both research and production of experimental and small-scale product samples before launching a new product or system in industrial production. R&D expenditures are an essential indicator of a company's innovation performance.

R&D phase is necessary if your elevator pitch sounds anything like "It's an Uber, but with X," where X is an innovation. X is something that no one in your niche has not tried yet, but you are sure it is a gold mine.

There might be either of two reasons why no one has not implemented it yet:

• It is actually a gold mine, and you are the first to find it.
• This innovation was tried out during an R & D stage and proved to be nonviable or too expensive to implement.

Let's take a look at a real-life situation where X is image recognition. Do you need R&D?

• Yes, if your target audience is big manufacturing companies that require highly precise image recognition. That means that you'll probably need machine learning to improve the recognition process. During the R&D stage, you'll figure out how long it'll take to train the model on the required data set, what's computing power you'll need, and how much time it'll take to develop. Having this information, you will be able to estimate what's that feature will cost you.
• No, if your app is yet another Pokemon go. First of all, time to market and staying on the budget here are more important than image recognition precision. Yes, most likely, in poor lighting and from an obscure angle, the app won't recognize a house/Bush/cat. Your "pokemon" might be rendered in the middle of a table, but that's not critical. Users are ready for this level of recognition in games and most likely will not appreciate all the effort you put into machine learning to improve image recognition. After figuring out if you need R&D or not, let's proceed to the features that a full-fledged app may or may not have. The first one to go is the offline mode.

Do you need your app to work offline?

If you want the application to be stable with a poor Internet connection (or without it), it requires additional investment. For example, a navigator app or music player needs an offline feature. Having the offline feature will help not to fall into the pitfalls of relying on mobile data only:

• Mobile network failures due to switching to roaming when traveling between regions/countries. This can lead to a navigator app ceasing to function. It is a bad scenario for a user and a bad review for you in the App Store.
• Fast device discharge due to the phone's constant search for the best signal. This situation may happen in sparsely populated or wild regions because there is a small number of mobile data towers. Obviously, a dead phone in an unfamiliar area is a dangerous situation. If this unfamiliar area is a forest, not having a navigator can be life-threatening.
• A complete absence of mobile data.
• Low connection speed. For a navigator, this will probably not be such an obstacle. However, it will definitely prevent you from listening to music, and nothing is more irritating than a broken record.

However, some apps do not need offline mode. The first thing that comes to mind is an email app and messengers. The offline feature can be useful, for example, to view the archive, find a funny video in your group chat, but this can not be considered a priority function when calculating how much time and money will be spent on development.

Do you need tablet support?

Tablets require a different design that is usually distinct from the design of a mobile app.

The iPad app is necessary for image editors, video players, and other applications with high user engagement in the process. Usually, the user is entirely focused on the app they are working with at the moment, not distracted by mail and messenger.

A good example here is the Procreate app, although their approach is a bit extreme for common use. Procreate created two separate apps, one for iPad, one for the iPhone. Both apps are paid, and both have their users.

An iPad app isn't going to be useful for apps like Instagram. People use Instagram on the go, in the subway, staying in a line. Every button there should be within thumb reach, which is clearly not the case with iPad apps.

Before you decide whether or not you need tablet support, think about how and where people will use it. Is it important that a person could keep a device comfortably with one hand? If your app is anything like Uber, think about whether it's important that a person could quickly get a device out of the pocket.

How many features and screens are there?

By application categories, you can roughly indicate how many features/screens you need.

The same mobile app functions can be implemented on five screens or one screen. The time for implementation, of course, will differ. A competently delivered design stage allows you to optimize the number of application screens, which results in a lower development cost.

For example, Netflix and Amazon Prime perform the same functions. While Prime needs one screen to show you the genres of a movie, Netflix uses 2.

Complex applications start with more than 25 screens. We define a complex application as any application that supports a wide range of unstructured goals or non-linear workflows.

Optimizing information to fit a lesser number of screens but still keep it easy to understand is work for a UX designer. You should also keep in mind that the importance of a certain type of information depends heavily on your app's purpose and specifics. For example, personal information in a social media app might take up to five screens, while for a music player, one screen of bio is more than enough.

Do you need a native or hybrid app?

There are not a lot of time-tested solutions on the market. We can even say there are only two: native development or cross-platform development on ReactNative. Such solutions as Xamarin and PhoneGap are being used less and less. There should be a really good reason to develop a new project using these technologies. Flutter is still a completely new platform; it's better to wait some time to make sure that it is viable.

We'd recommend native development, since in this case, you will definitely not face any restrictions from the platform, and the experience of using a native application is much better for the user. If you look at AppStore's top apps, you will hardly find a cross-platform solution in the first hundred.

Many of the most popular apps out there, like Pokemon Go, Twitter, and Waze, are fully native. However, it's becoming trickier to distinguish apps that use purely native code on Swift, Objective C, and Java from apps that rely on hybrid solutions or cross-platform SDKs, thanks to the advancement in hybrid technologies.

However, ReactNative cross-platform development has one big plus: faster and cheaper development for two platforms at once. It is good for MVP and hypothesis testing. Once the hypothesis is verified, you can develop a native app to improve the user experience. Moreover, over time, the "speed and cheapness" of development on ReactNative will decrease, and at one point, it may turn out that a certain feature is faster to develop natively on two platforms.

Also, it is easier to find a good expert in one area than in several areas. For a developer to develop a native app for iOS – they only need to know iOS, while to develop for ReactNative, the developer needs to know iOS, Android, and ReactNative at the same time.

Hybrid development seems to have its perks. Let's take a closer look at some well-known apps that were developed with this approach. Evernote is the best example to show that performance is not an issue now for hybrid applications. Despite its beautiful design, Evernote is extremely efficient in driving productivity. The intuitive and flawless functionality of Evernote is built with (mention the framework).

Another good example is Instagram. Adopting the hybrid approach has allowed its developers to build an app that supports both offline data and rich media. It must be noticed that Instagram used to have a fairly limited number of features and minimalistic UI when its creators chose the hybrid approach. If your app's UI is more complex, think twice before going for hybrid development.

Conclusion

Answering these five questions will help a technical person to better estimate how long it takes to develop a mobile app. Take some time to think over each of them. Even if the resulting time frame is longer than you thought, do not distress yourself. It is much better to learn about how long it takes beforehand than to face unexpected delays in the middle of the development process.