In a perfect world, every app development project would end on time, on budget, and be exactly what the client wanted. All of the details and designs would be perfect after the first meeting, communication would be simple and efficient throughout, and there would be no stress on either side. But we don’t live in a perfect world, and sometimes, projects can turn into a nightmare that leaves you never wanting to deal with an app again.
Our goal with every project is one thing: creating world-class mobile experiences that blow the doors off expectations. And we’ve learned that a big part of this is transparency between us and our clients. The more we know about you and the more you know about the app design process, the better. The saying goes that it’s important to learn from your mistakes.
Well here, we prefer to learn from other people’s mistakes. To do this, we’ve asked a couple of experts in the field for what they’ve experienced as red flags that could derail your project.
What do you look for as warning signs that an app project is going to have issues?
Senior Manager at Cisco
“Flags are raised when I hear overconfidence in regards to meeting performance metrics or the lack of bugs with an initial App release without a solid user testing/QA plan. It’s nearly impossible to satisfy all the variables that come with different smartphones, operating systems, and networks. First impressions are paramount for a successful App and a poor initial experience will most likely lead to App uninstalls versus waiting for an update.”
George R. Moskoff
Founding Consultant at APG Consulting
“The biggest sign of an impending disaster is the lack of a business case for the development effort. I’ve seen this over and over: someone gets an idea for an app and heads off to get it coded. No research on whether the design or the niche is in need of such an app. The owner will end up with an app that “sits on the shelf” and a bad taste in his mouth from the $30K he spent to get the thing built.”
“When the developer starts missing deadlines and then ‘status calls’, your deadlines are most certainly in jeopardy. Working with India based developers, as a woman, they don’t always listen to or respect what you tell them, so putting everything in writing is crucial. And when there is no bug tracker system to submit, track, and monitor fixes, there’s a chance that bugs get missed.”
Lead Program Manager at Y Media Labs
“A project could be destined to go overtime or beyond budget if the client is unable to make up their mind on the look and feel for the app, they are changing their mind after seeing other apps, or want to add features that were not originally planned for within initial scope (we call this scope creep).”
Founder at Nown
“Before signing a contract, try to understand the fluidity that exists between designers and developers. There is no point in spending money on UI and UX if features in the SOW (scope of work) are not possible. It’s best if the designers work closely with the developers and understand any API limitations before they spend the time, energy, and resources designing something that, ultimately, can’t happen. If a company says they don’t do design and will outsource this part of the app development process, in my opinion this is a big ‘No No’.”
“For me, a major red flag is if the technical PM (project manager) and/or developers don’t present me with a mountain of questions during a review of business requirements. That’s usually a symptom for all sorts of underlying problems that can derail the schedule. Maybe they think that they understand the requirements when really they don’t. Or they just don’t want to ask questions because they assume they understand based on the written brief. Regardless, when I don’t get any questions, I know that we’re all in for a rough ride.”
CoFound & Product Manager at Jawns
“Marketing, marketing, marketing. If you think you’re going to build it and then they will come, you are almost 100% wrong. It’s not like it used to be and the market is crowded. You should build social marketing features into the app and work with your vendor to see how they can help with distribution of the app.”
Lead Program Manager at Y Media Labs
“The client could never make a decision. Every decision point became a chance to open a new spectrum of possibilities, rather than narrowing them down. This can happen because the client isn’t sure what need they’re addressing with their product and they don’t really understand the space that they’re getting themselves into; they’re not their own target audience, nor are they likely to ever be users of the app.”
Chief Technology Editor at Druva
“Everyone thinks he or she is in charge. To demonstrate the need to be “part of” this important, career-defining project, every single stakeholder sees themselves as a dog that needs to mark their territory by peeing on it. When the review team keeps growing and changing, asking you to make changes that you addressed five versions ago (before they were on the team). Progress is measured by the number of fixed bugs and not completed features. Team members have fights over product specs, leaving the implementers at a loss to know what should be done (so should it be green or purple? Someone make a decision!).”
Do you have a story like these? We’d love to hear from you in the comments section below, or feel free to shoot us an email. Let’s not let the mistakes of the past stop us from creating the best apps of the future!