You’ve got a great idea for an app. You know in your gut it is gold. You have done your homework and asked around (with caution not to spread it beyond your most trusted circles so no one steals it). You, and everyone you asked, would use it. And you have the funds needed. Sweet!

You find a development team that seems capable, they have signed NDAs, and after a few sessions defining requirements together, they’ve finally got all they need. Development starts. Exciting!

What no one tells you is that building a mobile app is not easy and many times it ends in disaster. If the worst happens, you end up wishing to have a time machine to go back and tell your younger self the pitfalls of building your dream app. With this in mind, and based in the couple of decades of experience building complex digital platforms, the Dotsur team has compiled five causes of failure when building mobile apps (and digital products) and our recommendations on how to prevent them.

Mobile disaster #1: No one bought or downloaded my app

Not all ideas are good ideas. Many entrepreneurs have invested a great deal of time, faith, and money in a new app with the hope it will make them billionaires only to later realize that no one wanted it.

Ask ahead.

Before you embark on the mad race of becoming the new unicorn, ask these basic questions:

  • What problem are you solving? 
  • Do you have a clear definition and measurement of “success”? 
  • Have you run a market-fit analysis? 
  • Do you have a waitlist or a pre-order list? 
  • How will you compel your potential customers to buy and keep using your app? 

These questions may seem the most logical ones when you are about to invest tens of thousands of dollars in the development of a mobile app, but many of the entrepreneurs we come across haven’t thought about how they are going to monetize and market their apps. 

Lean Startup and Design Thinking. It is best to first hypothesize about your product and prove your theories before implementing them. Experimenting with your proposed solution iteratively, creating prototypes with multi-disciplinary teams that will help balance the usability, economic viability, and technical feasibility of your idea lowers the risks of failure when you decide to move forward with its implementation. The team defines the problem to be solved, researches how to solve it, comes up with an idea (or hypothesis), builds a prototype of the solution, and tests how a sample of the market reacts to it. Since no code is being written and tested, this process allows you to quickly find out if you need to pivot or tweak your solution to fit your market needs. 

Open channels to connect with your users.

Design your products and services so it is easy for your users to share their feedback. Learning from their experience is the key to keep your product current. 

over budget projects

Mobile disaster #2: My project went way over budget and the deadlines were never met

Estimating is not a precise science. It can be optimistic or pessimistic, but given that what we know at the beginning of a project rarely matches what we know when it ends, initial estimates should never be taken as the final word. 

A fixed price may not be the best price.

A fixed price agreement means the development company will deliver a product to your satisfaction for a pre-agreed price. Fixed-price contracts are great for projects of low complexity where a quick turnaround is feasible. When you are building an innovative product, your technology partner would need to cover for any unforeseen risks by adding cushion time to their estimates, which translates to additional costs. There is not a lot of flexibility if you want to change your scope or you need to pivot since a new estimate will need to be calculated, drafted, and approved. Hence a Time and Materials agreement (bill by the hour with expenses for the duration of the project) is preferred when dealing with innovation.

Get a process-oriented development partner.

Agile Development comes in different flavors, but they normally include a bunch of advantages over other methodologies like:  

  • Iterative deliveries. Go live fast with the minimum viable product and iteratively add new features while you learn from your customers.
  • Prioritized backlog: There is a backlog of features prioritized according to your business needs. The team always focuses on the top priority features first. 
  • Quick daily status meetings that allow for the early identification and removal of blockers
  • Demos. The demos were thought so you can test your app even in its barest, earliest states. This allows you to provide feedback at any point if the project instead of waiting for months to end up with a product you don’t want.
  • Transparency in how the team’s hours are being used. The Project Manager can predict if the current pace (velocity) and progress will cause over-budget or delays so you can make a resource allocation plan that matches your business goals.

Find an experienced team. 

We all like a bargain, but in the case of an app development, counting on an experienced team means minimizing the risks and maximizing what gets done. Past experiences help shape the specialists’ current success and reduces the number of bugs and mishaps once the app launches.

Consider augmenting your technical team. 

Staff Augmentation is a common practice startups use to grow their teams and boost their productivity by sub-contracting the most hard-to-find technical talent to maintain momentum. There is a great source of talented specialists outside the USA that can be onboarded for a while and always following your company’s processes and ground rules.

Global Platforms

Mobile disaster #3: Not Thinking About Global Audiences Early On

From a business growth perspective, it is better to start local and then think global. Not including the potential for  global scalability in the initial requirements can cost you in the long run since making a change in the architecture design phase costs 90% less than implementing it after the app has been delivered.

Include Global Scalability and Redundancy in your early requirements

Ensure speed and reliability for as many concurrent users the app may have notwithstanding their geographical location. 

Be redundant. Redundancy is basically not putting all your eggs in one basket, and it is a requirement when going global. Redundancy means having multiple data centers with a copy of the latest version of your app and your users’ data. It helps to minimize the risk of outages.

 

Mobile disaster #4: Not Thinking About Battery and Bandwidth Consumption

When users find out an app is draining their battery, they will likely uninstall it and look for an alternative. So, do not give your customers to your competition on a silver platter. When it comes to bandwidth, just consider the internet connection is not great everywhere you go, and some apps will need to be reliable even when the user is driving through a tunnel with a spotty connection. 

Design the app to work with average connectivity or be offline first. Also be mindful of the app features like background activity, location-based alerts, and inefficient refreshing that may affect battery usage.

 

Mobile disaster #5: The App is Not What We Asked For

In this line of work, we get to hear some “horror stories” about how mobile app development went awry. One of our clients didn’t get along with the development team, so he didn’t communicate with them. He didn’t want to attend the status meetings and just wanted to know “how they were doing,” which in the Progress Report showed always 90% done and green status. After months of waiting, the app was delivered with crashes and unwanted features. Our client had to start from scratch with a new architecture and development company and felt like they threw their money into a black hole. 

Stay Involved.

 If you are working with an Agile team, stay involved, attend the demos, answer questions, help with the decision-making process, continuously communicate your business needs, and do not let the development team become a “black box”.

Embrace transparency.

A good technology partner will be happy to do two very important things:

  1. Let you know early on about deviations in budget and timeline and work with you to reach your business goals efficiently and avoiding surprises.
  2. Share their progress, even when things don’t look great. A good technology partner will want to validate they are on the right track at all times.  

Prevent miscommunication.

Synaptic connections change from person to person, and our perception of the universe is different. A good rule of thumb is to never assume the development team understood what you asked for. Rather, enforce the Design Thinking process so you are always running experiments to validate your ideas work in the real world and have been accurately understood by the team. 

 

Do you have experience building apps? We would love to hear what do you consider being the key to either success or failure of launching a new app!