5 Mistakes Startups Make When Developing First App

5 mistakes startups make when developing their first app

Mobile apps can be a goldmine for a company. As a marketing device, or as an avenue to generate revenue directly, a well-designed app always delivers. However, there are many ways in which app development can go wrong, leading to a wasted investment. This is a particularly big problem for a startup, where a costly mistake can prove “deadly”. With that in mind, this article aims to cover five common mistakes that can lead to an underperforming app, and how to avoid them.

1. The backend infrastructure is not suited for mobile apps

You may already have a backend developed for your website, but a mobile app can generate traffic of a different nature. This is due to increased traffic and data requests. In fact, some companies see as much as a 200% increase in their traffic after introducing the mobile version of their app. If you think about it, it’s easy to understand why. A user will visit your website once or twice a week, handle their business and then move on. However, from mobile devices you will receive daily data requests as the app makes accessing your business easy. In some cases, backends go from weekly interactions to more than a few dozen per day (banking apps, for example).

This means that a good backend will have to be redesigned with mobile applications in mind. To start, the maximum payload size has to be adjustable from the client. The app works best when the minimum amount of data is sent. Pagination also has to be taken into account, and the backend should allow cursor-type and paginated results to be returned for list return types.

Other changes to the API have to take into account mobile network connectivity issues, latency issues, and the various versions of mobile operating systems in order to deliver the best experience. These changes to the backend are essential for a proper functioning app. Without them, the app will either be too slow, or it will hardly work at all.

2. The client is not involved with the mobile development company when outsourcing a project

5 mistakes startups make when developing their first app

In order to have the best results, it’s important to work together with a development company when outsourcing a project. An experienced development company will ask for a lot of documentation upfront, which covers much of the information needed to develop a competent app. Documents such as the business plan and the request for proposal, for example, cover everything from your marketing plan, to your competition, expected development methodology and technologies, business objectives, and many other vectors of information.

However, the best results come from collaborating closely with the development team throughout the project. Good development companies will ask to stay in touch with your QA, design, marketing and engineering teams in order to get buy-in from key stakeholders within your company, before going forward with a design decision or feature implementation.

This relationship also translates into direct experience for the client company as well. During this process, clients have the chance to understand the nuts and bolts of mobile application development, and then use that experience when working with an in-house development team in the future.

3. Building a cross-platform app when a native app would perform better

A cross-platform app comes with the obvious benefit of being able to reach a wider audience. All you have to do is code once, and then publish for all platforms. Many companies have chosen this route, including Facebook and Linked In. However, cross-platform apps lag behind native applications in terms of performance, functionality and in some cases, even, UI.

There are three types of cross-platform apps: those developed using HTML5, those developed using cross-platform toolkits, and hybrid apps. Each one of these has its own unique set of problems. HTML5 apps have cross-browser compatibility issues, which in most cases means that you have to optimize for each platform, but in a slightly different way than you would with a native app. Hybrid apps have a very complicated and error-prone communication layer between the app and web view. Even apps based on cross-platform toolkits end up needing large amounts of custom code for each platform, leaving them only slightly more efficient than simply developing a native app for each platform.
This does not mean that cross-platform apps are a waste of time. Today, the tools for developing cross-platform apps are more powerful and competent than ever. But when compared to a native app, a cross-platform app simply does not have the ability to provide a high end user experience.

Of course, it’s all about time and budget, but the best approach would be to develop a native app for your most popular platform first, and then expand to other platforms as you grow. This method gives you the advantage of improving iteratively with each new platform. It will also force you to take a more in-depth look at your audience’s preferences. You might be under the impression that your audience is mostly on Android or iOS devices, but upon closer investigation, you might find that they prefer Windows Phone or Blackberry.

4. Not using the outsourcing experience to develop in-house capabilities

5 mistakes startups make when developing their first app

As mentioned previously, you can learn a lot from the outsourcing experience, especially if you are hands-on during the project. However, all this information should be used to develop in-house capabilities.

Some mobile development teams will help you hire skilled professionals for your own company in order to speed up development. These in-house professionals can then handle support tasks, software issues, updates and many other aspects of app maintenance post-launch. Eventually, you could even have a complete team and develop all your apps in-house.

This is an especially advantageous service for startups, because having an external team on retainer can be daunting when your next round of funding is uncertain. Having an in-house developer or two will help you keep the app afloat while you take in new customers and search for new funding avenues.

5. Building an app internally when under a tight deadline

Mobile development companies offer a specialized service, which means that they have refined their processes over dozens, if not hundreds of projects. The developers are used to working together, the project manager knows how to prioritize and organize the team, and it all shows in the development time of each project. In fact, the difference between an inexperienced internal team and a specialized development company can be striking at first – the development team can develop an app 4 times faster than an internal team.

The reasons behind this gigantic difference boils down to several factors, one of which is hiring. Hiring presents significant costs both in terms of time and financial resources. It takes time to find people with the right skillset, get them onboard and get the project going. You also have to take into account various other aspects of app development, which are not directly related to engineering. You have elements such as UX and UI design, mobile QA, and of course project management. All of these skills have to be sourced either internally, by hiring new team members, or externally from specialized development companies.
However, once you have the team in place, your problems are far from over. There are cases in which you will have to bring in an external development team anyway, because the project comes to a grinding halt. Companies reach this position when they realize that they do not have the resources and personnel needed to finish the app. The external development team will then have to repurpose the app, and it’s not unusual for them to have to start the development process all over again.

Finally, an external app development company will already have invested a considerable amount in test devices or gathered an experience using cloud-based testing environments This can be another time and money sink if attempted in-house.

See also: