An overview of where most apps fail, and how to avoid each situation.

Here’s a terrifying statistic for any business that doesn’t have an app: today, Americans access the internet through mobile devices more frequently than through computers. And if your target demographic includes young people, the numbers are even scarier: one in five millennials accesses the web only via their smartphones. If you don’t have a well-designed mobile app, your brand is going to be quite literally invisible to the increasingly large demographic of mobile-first users.

The solution, of course, is to develop an app, but that’s easier said than done. And if you go into the process without a proper understanding of what to focus on, it can quickly become a quagmire. Case in point: the TSA reportedly spent hundreds of thousands developing an app so ridiculously simple that a relatively novice coder could build it in a matter of minutes. It was a colossal waste of time and money and an embarrassing PR gaffe once the story got out. The TSA probably doesn’t care much, because its annual budget is over $7 billion. But most companies operate on tighter margins and can’t afford to needlessly waste money in the app development process.

So don’t go the way of the TSA. Avoid these four major (and sadly very common) mistakes and you’ll be well on your way to developing an app that isn’t ridiculously expensive and has a good chance of finding the right audience.

Incorrectly Identifying the Audience

The first and arguably most important step in the development of any app is identifying who your target users are, and what they’ll want to use your app to do. It’s easy to say that you want your app to be like a mobile version of your desktop site, so it should include all of the desktop site’s functionality and content. But often, that’s overkill that can turn off mobile users, who are generally looking for a fast and convenient fix.

Moreover, your mobile and desktop users could be completely different people, or they could have completely different needs. Think, for example, about the way you use your bank’s desktop site compared to the way you use its app. You might turn to the desktop site to do something like look up a bank policy, make a series of transfers, or find the details on opening a new account. But when you’re on mobile, chances are you want to do one of only a few things: check your balance, deposit a check, or make a transfer. And the less obvious or more difficult your bank’s app makes doing those three simple things, the less likely you are to use the app for anything.

So your first step in developing any mobile app must be to identify who your users are, and what they’re likely to want from your app. Without this information, developing an effective app is virtually impossible, and the chances of you wasting your money skyrocket.

Choosing the Wrong Development Method

Once you know who you’re building your app for, you’re faced with another daunting question: do I go Native or Hybrid?

For the uninitiated, going native means developing an app specifically for a particular mobile operating system—so, for example, you might build one app specifically for iOS and then another specifically for Android. Going hybrid would mean developing an app partially using “native” methods and partially using HTML5, which makes it possible to essentially code one single app and still have it function across multiple mobile operating systems.

The conventional wisdom is that developing native apps takes more time and money but results in a better end-user experience. Developing hybrid apps, conversely, is generally quicker and will ensure your users across all platforms get the same experience, but the fact that hybrid apps aren’t fine-tuned to take advantage of each specific OS’s unique features can mean that they offer an inferior UX when compared to native apps.

Although native apps are generally “better,” they may not be the best choice for your company, so this is a question you need to thoroughly investigate. If you need to produce a best-in-class user experience regardless of development costs, then you should be writing native apps. Conversely, if you don’t, and if a slightly less polished user experience isn’t likely to significantly impact the revenue your app generates, then there’s little reason to invest extra time and money in developing native apps.

There are technical considerations here too, though. Depending on what your app needs to access, you may be forced down one route or another. For example, if your app works best when integrated with other apps, some of which are iOS exclusive, then native development may be your only option. Ditto if you app requires the use of a unique feature that only exists on one mobile OS (like iOS’s 3D Touch feature).

So, what’s your budget? What’s your time-frame? What OS-specific features might your app need? What level of user experience do you need to provide in order to satisfy your users? You need to know the answers to these questions before you begin the development process. If you start developing hybrid only to later realize you should have gone native (or vice versa), the loss of both time and money could be devastating.

Focusing on Features

Once you’ve figured out who your app is for and how you need to approach its development, the next step is typically to define what features the app will need. This is where it’s easy for companies to really go off the rails.

On its face, adding more features almost always sounds like a good idea. The more your users can do with the app, the more they’re likely to use it, right? Wrong. In actuality, adding too many features can be the death of an app, for several reasons:

First, mobile users are generally looking for a fast, convenient, and simple experience. If your app has twenty different features, chances are it’s too complicated to be fast, convenient, and simple… or too overwhelming at first glance for users to even bother figuring out. Many apps are closed and deleted within seconds of their first time being opened for this reason.

Second, not everyone is using the latest hardware. The more features you add, the slower your app is likely to be on older phones and tablets, and if your app is slowing down a user’s whole machine or crashing because it’s too demanding for the hardware, you can bet it’s getting deleted (and you’re probably getting a one-star app store review to boot).

Third, remember that people will be looking at this app on tiny, four- and five-inch screens. Your design needs to be aesthetically simple and clean for the app to be easily usable on a screen that small, and the more features you try to cram in, the more crowded that precious screen real-estate is.

Fourth, if you’re focused on constantly adding features, you’re probably not spending enough time thinking about engagement, and how your app will get users to actually use those features. Users aren’t always predictable, and every new feature you add will likely need to be tested and tweaked before it can effectively engage users. Putting in too many features is an easy way to run out your allotted time or budget before you’ve had the chance to do user testing and make changes to improve engagement. It’s better to have five features that you know from careful testing are going to engage users than to have 20 features you never had time to test or adjust.

So unless you’ve got unimpeachable data to suggest that your niche customers need a deep, complex app experience, you should be thinking fast and light when choosing the features for your mobile app. Don’t go overboard; instead focus on the few core functions that the app will need to satisfy the user needs you identified as part of #1. If you’ve got extra time or budget, spend it on improving engagement through fine-tuning the experience of those core features rather than shoving more features into the app.

Not Using Analytics

Here’s a mistake that happens frequently because of sheer carelessness: forgetting to include some kind of analytics tracker in your app.

It’s easy to make this mistake because during the development process, you’re often going to be focused on the user experience and what your app is doing for users. But don’t forget that what the app can do for you is just as important.

The specific metrics you want to track will depend on your business (although everybody needs the basics like user activity, retention rate, and time spent in app). But without some kind of tracking, you have no way to know how well your app is doing. More importantly, you have no way to know the ways in which it might need to be improved. You’d never launch a new website without analytics tracking, and you shouldn’t launch a new app without it, either.

The good news is that there are lots of companies that provide premade analytics solutions, so you probably won’t have to pay to code your app’s analytics features from the ground up. Flurry and Mixpanel are popular choices, as are Google’s Universal Analytics and Apple’s App Analytics.

It’s about thinking ahead

In the end, developing a good mobile app is mostly about thinking ahead and very carefully figuring out what you need and why you need it before the development money starts flowing. If you can avoid all of these mistakes, then you’ll go into the actual developing knowing who your customers are and what they’ll want from your app. You’ll know whether your needs best fit with developing a native or hybrid app (so you’ll have budgeted accordingly). You’ll have a short list of essential features you’ll need to create an engaging, simple, and functional app, and you’ll have a plan for tracking data on the back-end so that you can tell how your app is being received.

If you’ve got all that, then you’ve avoided four of the major pitfalls of mobile development and set yourself on the road to success.