App Development Risks

What are the app development risks that you will likely encounter on your app development journey? What are the things that could go wrong vs. the things that are more likely to happen?

As a software entrepreneur, you’re standing in front of an ocean you need to cross. You don’t really know what you are going to face or what is in store for you during this journey.

Let’s go over some of the things that could go wrong. These are the things that software entrepreneurs are afraid will happen. Then let’s touch on things that are more likely to happen, because what could happen is very different from what likely will happen. Hopefully by the end, you’ll feel more confident about the journey.

Imagining the Extreme 

Here are two major concerns that I hear from prospective clients all the time. There are two major concerns:

1. Your vendor is going to steal your money. This probably won’t happen. I haven’t run into any offshore software vendors that were just waiting for that initial wire transfer and then just made off with client funds. That’s more of a scenario that you’d find in your spam folder from a Nigerian prince.
2. Your vendor will steal your intellectual property, make an app from your idea, and then hit it big, beating you to the market. But don’t worry an NDA will cover that right? Right? This is also very unlikely. If someone were to steal your intellectual property, they likely wouldn’t have the industry background that you have and wouldn’t be able to bring a product to market based on your know-how and expertise. After all, you’re the one that’s been working on the app concept, validating it, testing ideas with target users. You’re the one that feels passionate about this specific mission. Also, software vendors aren’t looking to become SaaS product owners. They simply don’t have the interest or the ability to market a product like yours and make it successful. You bring the rocket fuel. They’re just building the rocket. They are like engineers who aren’t interested in going to space. They just want to build stuff and get paid. For them to steal your idea would mean significant risk of their resources. They’re just not interested in that risk.

Common App Development Risks

Shifting away from the extremes that “could” happen, here are some things that are more likely to happen:

1. You lose a developer. This happens all the time. A developer quits, gets sick, or simply loses interest and disappears, especially if you’re working with a solo freelancer. It’s not as much of an issue if you’re working with an agency. When you lose a developer, it can put your project behind schedule; which may be a source of headaches and stress for some time. And once you find another developer to fill in, it will take some time to get them up-to-speed.
2. Your vendor misquotes or underestimates your cost. They did poor due diligence or under-projected the requirements you gave them. As a result, the time and manpower that it takes to finish your app comes out to be more than initially expected… As a result, the price will increase and potentially skyrocket for all the overtime and additions that your app requires. Chances are the vendor isn’t necessarily being malicious. They probably just don’t have a good process for estimation or they have a disconnect between sales and delivery. After all, estimating software development can be very hard. You don’t necessarily need to have someone with a perfect track record or estimation process. You just need someone who will treat you fairly and keep their promises.
3. Your vendor renders “services” to you that achieve your outcomes, but aren’t really what you paid for. For example, you might be paying for “DevOps” services. Normally, this refers to the building of deployment pipelines that your developers can use to deploy code from a development environment to a test environment and ultimately to your end users. What the vendor is really doing is just having someone deploy your code manually without the automation and billing you for “DevOps.” This could be partly because not everyone understands what DevOps really means. So they might think they’re being honest with you, but what’s really going on is that either you’re paying for automation that you’re not getting or you’re paying for someone the vendor calls DevOps, but they’re really just a release manager. If all this DevOps stuff is confusing to you, read DevOps for Entrepreneurs to learn more.
4. You add more and more features. Another risk is that you may become too excited and want to add a bunch of stuff. You think your app needs this, and this, and that, and before you know it, the app is barely within the budget, and now you are caught in a tight space. The best thing you can do in this situation is ask yourself if you really need to have those features for your MVP release. Chances are you can get by without them and add them later. If you keep adding features, your timeline will get longer and your cost will increase. A good thing you can do to mitigate this risk is to work with a company who can be your partner and provide product management services to help guide your decisions on what’s in vs. what’s out. A lot of companies will just take your order and build whatever you say. After all, they’re financially incentivized to build more stuff. You want to work with a vendor that will say, “You don’t really need this and here’s why.” A vendor that will turn away from added scope to help you do the right thing for your product is the vendor you want.
5. You build features your users don’t need. Sometimes you will have a great idea to build a certain feature, only to find out that your users don’t use it. This is where it’s important to tell the difference between your own ideas and feelings and what you’ve validated with your target users. Basing features off your value proposition is a good first step to mitigate this risk. Also, validating concepts with your target users while the features are still in design can help avoid spending money on features you don’t need.

Real Challenges in Mobile App Development

All of the things listed above could happen. But it might be helpful to hear about some real experiences that we did have either on our own projects or working with clients. Here are a few incidents that come to mind.

With one client we found that in order to  develop the app, we would need a third-party license that was very expensive. It was a license that the client wasn’t willing to pay for, but having it would solve the problems that we faced. Instead we were told to find a different way to solve the problem. We ended up spending three weeks trying to solve this issue without success. After discussing the situation with our client we were eventually able to agree to a workaround, but it felt like we were being asked to fly to the moon without any rocket fuel and we lost time and money as a result.

On a different project with a client, they wanted to support different languages. After agreeing to do this, we were almost blindsided by the amount of complexity the increase in languages caused with the app’s workflow. The release of the beta app was delayed a month as other issues were encountered, and testing the app was delayed and took longer than expected (we wanted to make sure the app was functioning smoothly in the different languages).

On one project, we built something that went against the App Stores’ terms and conditions. We built a product for a client that created a credit / token model for consuming experiences in the app. At that time, it broke Apple’s rules and we couldn’t launch via the app store. We had to come up with workarounds, none of which the client really liked. In the end, we had to put the mobile app on hold and focus on the client’s web portal. Since that time, Apple changed their terms of service, so you’ll want to become really familiar with the Apple App Store Terms of Service and the Google Play Terms and Conditions and keep current with their changes.

Early on in our history, we made the wrong decision about hybrid vs. native. Fortunately, it was our app and not a client product, so we didn’t put anyone else’s money at risk. Previously in my career, I led the product strategy on a really cool mobile app. The developers working on it constantly complained that it was a web hybrid app and not a native app. They referenced the app’s speed and performance, as well as things we couldn’t do because we didn’t have access to the native features of the device. I was determined to avoid those problems and told myself that we would prove out our MVP on iOS and then follow up with the native Android version later. We went with iOS native. Yes, the app ran smoothly and didn’t have those performance challenges that other app had. But then when I shopped the app around, clients asked, “Is there an Android version?” I had to tell them no. It was a huge barrier to them adopting our app and blocked our cash flow, since people wouldn’t buy. This was very early on in the history of the company and we have since built lots of great products. But at the time, it was a devastating blow. If you’re building an MVP, use a hybrid technology so you can build your app once and launch it to both Apple and Android devices. For more information, check out our article about native vs. hybrid technologies.

There’s a quick overview of app development risks, including what could happen, what will likely happen, and a few things that did happen to us.  Risks have been and always will be a part of the journey, especially so when it comes to expanding your horizons and learning new things. Here’s wishing you the best on your journey, and if you have any other questions for navigating this ocean, check out some of our other articles and videos.