8 Mistakes to Avoid When Developing a Mobile App
Tim Bornholdt
Published on April 8, 2016
Despite your best efforts, you've probably worked on some projects which didn't end well.
We're no different. Even though we're one of the top app development companies in the Twin Cities, we've certainly made some mistakes along the way. In our opinion, mistakes aren't necessarily a bad thing; you learn more through your struggles than your successes (as long as you actually learned a lesson and don't repeat the same mistake).
In that spirit, we wanted to share with you a few reasons our app projects have failed, as well as some tips so you don't make the same mistakes we did. Here are 8 mistakes to avoid when launching a mobile app.
Poor communication between us and the client
Nobody expects 24/7, real time updates on the progress of their project. At the same time, building an app in a black box is equally unrealistic.
People are generally empathetic when deadlines get missed. Everyone has missed one in their lifetime, and it's never fun to go hat-in-hand to a client and tell them that their project won't be done when you promised.
The projects which have failed more often than not are when we are set loose to build an app, and then we don't hear from the client for weeks. When we finally do connect, we show them our progress and they are completely disappointed because they were expecting something else.
How to avoid this problem: Set a weekly check-in meeting with your developer and stick to it. If you have project milestones, reference them and see how close your team is to hitting those marks. Since a lot of app development happens behind the scenes, don't expect all of your updates to be things you can see. However, ask questions and get an understanding of where the project is at. If you're building a house, you might not understand why a team is digging so deep to set their foundation, but if you ask them why, they'll be glad to tell you.
Unclear/poor expectations set up front
When we first started doing client work, we made a lot of bad assumptions in our contracts and initial discussions. It turns out that some clients insist on taking phone calls at all hours of the day. Some clients would assume that if a deadline was missed, they would receive a credit on their invoice.
The worst failures for us came in the form of misaligned expectations on the final deliverable. We would have a rough idea at the start of what clients wanted, but we definitely did not ask enough questions and get clear parameters set. Because we made too many assumptions and didn't explain clearly what we could deliver, those projects came to an abrupt and unpleasant halt.
How to avoid this problem: Talk about your process with your developers before beginning. Understand when you can expect updates and when you can access builds. Be sure that the parameters of the project are well defined (especially what constitutes a completed project). Agree to clear consequences for failing to perform.
Inability to adapt to external changes
Apple developers are well acquainted with the story of Karelia Software, who built a tool called "Watson" in 2001. The story is so prolific that at Apple's annual developer conference, developers wait with a slight twinge of worry about who among them is going to be "Sherlocked".
External factors certainly have led to some of our projects ending unceremoniously. One of the most common factors is when Google or Apple release a new version of their operating system, which tends to happen once a year. New OS releases bring new features, which bring new bugs and new dependancies to account for.
Another problematic external factor is when another team beats you to the market with the same app concept. The larger your competitor, the easier it is to throw in the towel.
How to avoid this problem: Be flexible, yet confident. If you really believe in your idea and have a great strategy for building a killer app, then don't be dissuaded if your competitors get to market first. If a new technology emerges that you want to implement in your app, discuss the impact of the changes with your development team. Generally, changing scope is going to change the timeline and budget for the project.
Team members leave with no notice
Your team is made up of people, and people do all kinds of crazy things like have babies, move across the country, get injured and leave jobs. When you have a small team where everyone is playing an important role, a single dropped ball can be disastrous for a project.
One of the most stressful things about running a business is all of the "what-ifs" that can pop up out of nowhere to shut you down. The same things that can break a business are the same things that can impact your app project: developers have left us halfway through a project, leaving us with the problem of needing to replace them quickly.
How to avoid this problem: Working with a consultancy like the Jed Mahonis Group (:cough, cough:) shifts that burden off of your shoulders and onto ours. But if you're starting an app project with a technical co-founder, make sure they're willing to stick it out for the long haul. If you do need to find a new developer halfway through a project, see if your current developer can stay on board to help train the new team. If worse comes to worst, see if they can at least answer questions as they come up.
Shipping a product without thorough testing
Oof, this one is probably the most embarrassing of them all. There has never been a piece of software written that is bug-free. However, as a development team, you should feel comfortable with the bugs that are shipping in your products. It's never good to find out about a bug by reading multiple 1-star reviews on the Play Store.
What's worse is when your customer comes directly to you with a bug report. Naturally, you want to have it solved right away, but your development team may be focusing on a problem which is affecting even more users.
How to avoid this problem: Make sure you have a thorough testing plan in place. Your development team should have a dedicated QA person (or people) who can put the app through the paces and discover all kinds of crazy edge cases. At the same time, you should understand that your product is going to have bugs, and it all comes down to prioritizing the order in which you fix them.
Not having a model for monetization
There are a ton of app ideas out there which would solve a lot of people's problems. However, just because an app could solve a user's problem doesn't mean they will be willing to fork over cash to solve it.
In our early days, we would take any client regardless of their plans for how their app would make money. None of those clients panned out for us (probably because, shockingly, they didn't make any money). Since then, clients who approach us and say they haven't thought about their revenue model is a huge red flag.
How to avoid this problem: Consider your user and determine if your problem is actually big enough that it can make money. Choose an appropriate revenue model for your app and make sure it can make enough money to sustain an entire development team.
The app's user experience is bad
In 2008, a poor user interface wasn't necessarily something that would've tanked your app project. In fact, I bet if you work for a large organization, you have to use some pretty awful-looking pieces of software to get your job done. Hard to believe the fact that your organization paid for those at one point, right?
When we started developing in 2011, we didn't need to worry too much about design (which worked great, since neither myself nor my business partner are designers by trade). Our first apps looked pretty plain jane, but at a minimum, we made sure that users could intuitively find all the features in our app.
However, in 2016, shipping an app with an ugly design and poor user experience is like shipping The Homer. Users expect apps to be functional, beautiful, and easy to use. It's painful enough for us to admit that we've shipped ugly apps in the past, but it's brutal to admit we've shipped apps where it's not immediately clear how to use the app.
How to avoid this problem: Hire a designer who specializes in mobile app development. Design isn't just what you see, it's how you interact with the app. A competent designer will make sure your app works as beautifully as it looks. An ugly app which gets the job done is far better than a gorgeous app which doesn't.
Scope Creep
Ah, yes, finally, we reach our beloved friend: Mr. Scope Creep. For the uninitiated, scope creep is when the requirements of the project change during development.
For example, let's pretend we are building an app which takes a photo from your camera roll and sends it to another person. Halfway through testing, you now want the app to take a photo from the camera itself and send it. That is what we would call scope creep.
Scope creep has certainly killed some of our projects, particularly our first projects. It's really difficult to estimate what it's going to take to build custom software. Apps are living organisms; they're going to grow and change with time, and when costs and timelines don't also grow and change, projects end badly.
How to avoid this problem: When a developer quotes out a project, build in some wiggle room to your budget and timeline to account for unforeseen changes. If you think a feature needs to be added to your app, bring it up early with your development team and figure out what affect it will have on your project.
The best piece of advice we can give on scope creep is this: there will always be another phase. Write down your change somewhere, put it aside, ship this phase, and reference your list of changes in your next phase.
We might be great developers, but we're also human. We've made mistakes, and we'll keep making mistakes in the future. However, great developers learn from their mistakes and bring that insight to future projects. We'd love to bring our experience and talent to your next development project! If you're in the market for a quality iOS and Android app development company, give us a shout today!
