3 Cautionary Tales of Mobile App Development

Some cautionary tales to help you avoid some common pitfalls and instead, choose a build process that emphasizes quality early on.

by Jay Newlin

I once worked for a company that specialized in rescuing software projects when they hit disaster. The company was aptly named DmgCtrl (pronounced “damage control”). We were a lot like an EMT or open heart surgeon but for custom software.

I’ve worked in the software industry for 18 years, specifically in quality assurance (QA). Every development company does some level of troubleshooting and problem-solving, but what we did as DmgCtrl took that to a whole new level.

I hope that these stories, coming from a QA Engineer at that, serve as cautionary tales to help you avoid some common pitfalls and instead choose a build process that emphasizes quality software development early on.

Story A: College Scholarship App

Illustration by Andri Ardianto on Dribbble

The company’s idea was fantastic: How can we help high schoolers connect with scholarships to help pay for college? Believe it or not, there are a lot of scholarships that are not awarded because students aren’t aware that they exist or how to apply for them!

The team spent lots of time and money focusing almost exclusively on the user interface: how to make completing a lengthy questionnaire cool and engaging. An admirable goal.

But it came at the expense of fully developing its true “secret sauce”: quickly gathering pertinent information from the students to match them accurately with all the scholarships they might apply for. That, and having a database of all the available-but-underutilized scholarships and the determining factors for a successful match.

Illustration by Ewa Geruzel on Dribbble

They had a beautiful, fun-to-use mobile application that tested really well with students. But it never went further than looking pretty and cool. Without that backend, the app never matched anyone to anything.

The moral of this tale: Do your homework and focus on quality of engineering process so that someone else doesn’t come late to the market and still beat you with a stronger game.

Illustration by tubik on Dribbble

Story B: Dating App

We helped to rescue a dating app that was faltering because of frustrated reviews and an alarming number of users abandoning the idea and deleting the app. They weren’t heartbroken at being matched with the wrong person; they were just fed up with the frustrating user experience and bugs in the app.

The idea was a brain child of their founder’s personal experience with dating. He figured that single people would find it valuable to get one match a day from friends of friends. The idea was that having friends in common indicated that you would probably have things in common with the match. He also knew exactly how the app’s user experience should encourage the people being matched to talk to each other -- not just gape at pictures and swipe left or right.

Animation: A series of toggles labeled "Cheap", "Fast", and "Good", where it is only possible to select two
Animation by Philipp Klaus on Dribbble

It was 2013, the heyday of dating apps. There wasn’t enough time to consult with users, let alone involve them in the design process. Most features were deployed without much testing. The mission was about getting the product to market fast. (Everyone was still in love with the Facebook motto of “Move fast and break things.”)

Graphic: A flowchart describing the "Old Process" of idea, design, code, deploy, and the "New Process" of idea, workshop, design, workshop, code, test, deploy

Then the bad reviews, app abandonment, and a huge backlog of bug reports landed. Some saw the same match too many times. Some saw that they had exhausted the pool of singles in their area when there were clearly more. Some enthusiastically clicked into the details of a new match only to have the app freeze and crash.

18 months later, the company made the hard decision (under the guidance of some new investors) to do a complete redesign of the mobile app and the full experience -- and their development process itself. They let go of key staff. They brought us in to help with research, good design, QA practice, and engineering management.

Story C: Time to Take Your Medication App

Mockup by CMARIX TechnoLabs on Dribbble

A well-known pharmaceutical company came up with an interesting way to help their patients: a mobile app to remind people to take their medication on time. This is especially important for those whose medication schedules are complex or those who just need an additional memory boost in the form of a notification. Great idea! People will love it, and it’s a great way to keep the company’s name in front of their customers!

Their feature ideas were brilliant. And they had scores of them! The tech team came up with several. Marketing added their ideas. Medical recommended a few about maintaining overall health. Legal reviewed everyone’s ideas, adjusted them, and added one or two more.

For the sake of privacy, let’s just pretend that, instead of an app, they are hosting a picnic. The ideas range somewhere from we need a carved ice swan to a live microbrew operation to a satin hammock for the elders.

Graphic: A venn diagram outlining "What Engineering Wants", "What Users Want", "What Sales Wants", "What Marketing Wants", "What Legal Wants"

The problem isn’t the ideas. It is more that there isn’t someone taking a hard look at each picnic amenity and evaluating how these amenities fit together or whether people will use them. And when only a few people show up to the picnic, they decide to add a few more amenities, to attract people that they really wish would come.

As full-featured as the app was, the adoption in the market turned out to be far lower than they anticipated.

What happened? Why didn’t people want to use this fantastic app with all its cool features?

The product team forgot to include people who would actually use the app in the planning and design phases. Just because a very smart person in a large company thinks that they have an idea for a great feature doesn’t mean that others will want to use it.

They abandoned the app, which is sad because there are plenty of similar apps available to do the same thing. The others tend to be more successful because they’ve stuck with the basic features (medication reminders) and added those that users agree would help them as they manage their health.

Considering a custom software build for the first time? Check out our short guide “3 Things to Consider Before Building Custom Software”!

We'd love to keep in touch!

Opt in for occasional updates from us. Privacy Policy