When you’re building an app, it’s much more important to know what not to do than it is to follow a step-by-step checklist that lays out the path to success.

There’s a good reason for this – every app’s path to success is different, and something that’s right for one app could be completely wrong for another. The number one rule to successful branding is to differentiate yourself, and apps are no different. If you’re doing the exact same thing as a competing app, there’s no reason for users to try out your own.

That’s why this blog isn’t going to focus on what to do, but rather what not to do when developing your app.

Development pitfalls

Here’s what you shouldn’t do when building your app:

Make on-boarding difficult

When a user opens up your app for the first time, you want to make a good impression. The home screen of your app should instantly display the value of the app to the user – this can be achieved through obvious symbology in your navigation bar, or a quick, quippy, and enticing sentence that sums up what the app does.

Always make on-boarding achievable in the least possible amount of steps – you want users interacting with your app’s actual features, not spending time setting up accounts. Speaking of accounts…

No alternate options for logging in

If your app requires users to sign in, give them multiple options to do so. Some users will prefer to sign in through a social account, as it’s usually quicker than setting up a native account through the app.

Other users, however, prefer to set up a native account through your app, for many different reasons – some of those being security-minded users that don’t want your app to access their social data, or users who don’t have social media accounts.

Those who sign in with social media and those who don’t are both significant groups, so you want to make sure everyone has access to the option they prefer. Also, make sure you have enough social media options to link to.

Asking for payment info too soon

If your app requires access to a bank account, credit card, or online payment service like Stripe, don’t ask your users to input that info immediately after opening your app. Only request this info right before a payment must be processed. If you give users a chance to navigate through your app and figure out its value and the services it offers before asking for personal payment information, they’re much more likely to stick with your app.

For more info about asking for payment info and the effects it has on user retention, check out our blog on the topic.

Not conducting market research

Remember: just because you like your idea, it doesn’t mean everyone else will. Just like any product, apps must be based on market research – if there’s no one interested in your app, there’s no market to grow into.

More specifically about market research…

Not finding a niche

Like we stated above, the number one rule to branding is to differentiate, and it’s no different for apps. To quote Marty Neumeier’s Brand Gap, “when they zig, you zag.”

Conducting market research to determine what type of app people would be interested in isn’t enough – plenty of people are interested in ridesharing – but there’s already plenty of apps that have saturated this market. Think about how Spotify differentiated itself from Pandora – it’s a music streaming service, but while Pandora brings the music to you based on one band, with Spotify, (at least originally) you find the music you want to listen to.

These differences in design appeal to different audiences, which is exactly what you want to do. Lyft didn’t try to take away satisfied Uber customers, they researched the segments of users that were dissatisfied with Uber’s service, and then found out what they wanted. Then they did that.

Find a niche, and cater your app to their needs and wants.

Copying competition

As Nick Jones, NS804 CEO says, “Do your one thing and do it well.”

While it’s extremely important to keep track of what your competition is up to and how they’re doing it, it’s so you can take what works and then mold it to your own brand. If you’re outright copying, users will notice, and they’ll ask themselves “why don’t I just use the original app?”

Know what your competition is doing so you can capitalize on their good ideas and then head in your own direction. Stick to your tribe.

Trying to accomplish everything

To reiterate the point from above – it’s always better to do one thing well than it is to do multiple things mediocrely. Find your niche’s pain point, and then focus on solving that, and nothing else. Figure out ways to streamline the solution you provide. Every feature your app utilizes should in some way provide a benefit to solving your niche’s pain point.

By allowing your app’s scope to creep past your original idea, you can spell the doom of your business – for each feature you add, you add to both your time and cost invested into your app. When first starting out, provide the minimum amount possible to truly solve your niche’s pain point, and nothing else. Once your app is gaining traction, then you can go back to the drawing board and figure out what to add (but make sure the features you add still revolve around the main purpose of your app.)

For more tips on avoiding scope creep, check out our blog on the topic.

Not considering the use case

It’s easy to say “I want to make an app that helps connect people,” but what’s difficult to imagine is the way they will actually use it. When you have a vision or a brainchild, it’s not only difficult to throughly communicate your idea to other people, it’s also challenging for them to use it exactly the way you imagined they would. Everyone’s a little different, and because of this, use things in different ways.

There’s a few things you can ask yourself to help figure out what your app’s use case will be:

When will the user open the app?
Where will the user be when engaging with the app?
What solution will they expect?
How much time will it take to complete a session in the app?
What problems will they run into while using the app?
What corners will they try to cut while engaging with the app?

The more specific and narrow you can get with these questions, the better. Figuring out the answers to these questions can be achieved by through testing.

Multi-platform launch

If you’re making a hybrid or progressive web app (which we don’t recommend), this won’t really matter – but if you’re investing the time and money into native development (which is the more substantial option for long-term app growth), it’s much better to focus on one platform. This is for a few reasons:

Android and iOS apps are built using different coding languages
Each platform requires its own dev team, as well as its own round of beta testing
For every platform you release your app on, you increase your post-launch costs
Each native app requires significant time to build

Choose one platform to focus on in the beginning – once you have a substantial user base, and have a steady stream of income, then think about venturing to the other platform.

Not considering different markets on different platforms

This is another reason natively-developed apps are better than hybrid – Android and iOS users expect and interact with apps in different ways. From style guides to user culture, Android and iOS apps are very different in their methodology and feel. The market research findings you make about iOS users will most likely be different than the insights you make when speaking with Android users – even when your app ultimately functions the same on both.

If you’re having trouble figuring out what platform would be best for your app to launch on, check out our blog about deciding which is best for you.

Insufficient beta testing

While testing adds more time and cost to your initial development cycle, it ultimately saves you time, money, and headaches in the long run. Testing should be conducted continuously throughout your development cycle – test your app after every new build and iteration.

Users are fickle and will abandon an app for almost any reason – you don’t want to end up dealing with low user retention because you skipped this important step.

For more information about conducting beta testing on your app, check out our blog about it.

Ignoring A/B testing

Yup, there’s more testing you should be doing! If you’re unfamiliar with what A/B testing means, it refers to switching out one piece of data with another to see how it performs with users. For example, what happens if you switch the color of interactive buttons from blue to green? What if you switch the icon of your app in the app store to a different one?

To successfully conduct a round of A/B testing, you need to have a firm grasp of your analytics both before and after the change – then compare the two values to figure out which version is more effective.

Speaking of…

Not checking analytics

There’s nothing glamorous about analyzing data, but if you’re not, it’s like driving a car, down a mountain, with no brakes all while blindfolded.

That might seem like a bit of a hyperbole, but analytics is more than your conversion rate – platforms like Kumulos provide information about errors and crashing, what types of devices and platforms users are accessing your app from, what time of day they’re engaging with your app, and even what country or state they live in.

Knowing how your app is functioning among it’s niche is crucial and necessary to its continued growth and retention.

Putting user acquisition over user retention

It’s easy to get excited over your download rate – after all, if users aren’t downloading your app, how will they interact with it? While acquisition is incredibly important, retention is even more so. It’s the same rule as in sales: it’s always cheaper to retain a client than it is to find a new one.

Your efforts should always focus on keeping your returning users happy – if they’re happy, they’ll provide your app with positive reviews and scores, which will boost its rank on the app store, which in turn will lead to a higher conversion rate. Remember – word of mouth is the most powerful and effective marketing tool.

When you make your current users happy, they’ll do your marketing for you.

Not interacting/engaging/updating

There’s nothing creepier than a ghost town, and your users will notice if your app becomes one. Regularly update your app – this shows your users that you care about their experience with you app, and it also serves as a reminder that your app exists, and there’s something new to check out.

If a user leaves a review, respond. People like being heard. Use push notifications and proximity marketing to add different channels of user engagement to your app’s repertoire.

No post development plan

App lifecycle management is crucial to your app’s growth and success. To properly manage your app’s lifecycle, you need to focus on:

Keeping track of your competition
Providing major updates to UI and security
Offering additional solutions through your app
Adapting to current trends

When it comes to anything that works on code, development is never truly over. For your app to stay relevant, you need to show your users you’re ready to adapt to our ever-changing world. Those who stay still get left behind.

Expecting immediate ROI

Your app won’t immediately start making money after it’s published to the app store. Plan in advance for this – the first phase after launch is implementing your ASO campaign. It’s when users are engaging with your app that you’ll begin to see a profit, and no earlier.

Not considering hidden costs

Remember – publishing to the App Store and Google Play requires a publisher’s fee. The App Store’s fee recurs annually, and Google Play’s is a one time deal.

Hosting the backend of your app will have recurring costs (usually monthly) and your analytics platform will also be a recurring cost (usually monthly as well).

For more information about the hidden costs of developing an app, check out our blog on the topic.

Follow your own path

We hope you’ve found this list of what not to be helpful. But always remember one thing – if it works for your app, it works. Don’t worry about fitting the mold – be different, and be daring.

App development pitfalls