7 Mistakes for Mobile App Developers to AvoidJun 16, 2015 - by Cody Bunea
Congratulations, you’ve won the mobile app pitch! Now it’s time to deliver all that you’ve promised to the client, in a way that’s both time and cost effective (the hardest part). Prior to the acquisition by Sailthru, we launched Carnival and our mobile marketing automation platform. And before that, we were app developers, building apps more than 120 apps for some of the world’s biggest brands, including Kraft, DreamWorks, and Coca-Cola.
Developing apps, you quickly learn the devil is in the details – and the seemingly smallest mistakes can cause you to lose loads of valuable time and hard-earned money. We no longer develop apps, but to every mobile agency we work with, we recommend they watch out for these seven sneaky pitfalls.
1. Being Ambiguous on OS and Device Support
Turning in a proposal that’s short on detail jeopardizes your relationship with the client. If you don’t specify that your estimate includes iOS development only, for example, your client may expect that your costs include Android. Or if it won’t work on iPad, it will be your responsibility to fix it for free if the device isn’t specified on the contract. Deviating too far from your initial estimate can kill a project outright, no matter how close to locked up it may seem; so make sure your contract indicates device, version, and OS support.
Do: Set clear expectations about development costs from the start, including a breakdown by operating system, device, and version in the project scope.
2. Starting Development Without a Formal Change Request Process
Expect your clients to want at least minor changes throughout the project without affecting the timeline. Straying too far from the agreed project scope will cost time and money, as even minor changes add up. Prevent “scope creep” by introducing a formal change request process that allows you to push back on changes. Explain upfront that changes will increase cost and development time.
Do: Create a formal request process for any changes to your agreed upon project scope.
3. Falling Into the “App Developers who Reuse Old Code” Trap
Words that make app developers cringe: “It’s just a straight asset swap, right?” From your client’s point of view, it seems entirely reasonable to reuse old code to save both time and money. Unfortunately, unless the code was specifically designed to be reused, and was written recently, it may take you more time to build upon this old code than if you just wrote what you needed from the start. Remember, if you agree to reuse code, you’re also agreeing to fix bad code if that’s the case – always more of a headache than it’s worth.
Do: Avoid reusing code that you didn’t write yourself.
4. Skimping on Wireframes and Mockups
Often, static wireframes aren’t sufficient for demonstrating to a client how their app will function when live. Help your client visualize the app before starting development and avoid an endless cycle of revisions, through a design and wireframing process that includes interactive prototyping. Allow at least two or three rounds of design and approvals in your project timeline to make sure your client is happy and knows what to expect once their app is built. Some tools we like: Atomic, Proto.io and Frame for prototyping, and Sketch.io and Photoshop for wireframes.
Do: Use interactive prototypes instead of static images for complicated animations, to reduce changes during development and ensure you’re delivering what the client expects.
5. Setting Inaccurate Cost and Time Expectations for Complex Tech Features
It’s tempting to give optimistic development estimates for complex features like CMS or notifications, but what makes them happy during the pitch, can become a point of contention once the project schedule starts to stretch. Be upfront about feature costs and development time (lean on dev calculators), and use that as an opportunity to explain why it’s complex. If the cost or time for a feature remains a difficult point, make sure you understand their business goals for the app, and whether that feature helps accomplish them, or if it’s better left out of the app entirely. No need to recreate the wheel — many advanced features are more effective and cheaper through a third party.
Do: Be realistic about development time and costs for complex features, and make sure every complicated feature is necessary to achieving your client’s app goals.
6. Poorly Defined User Acceptance Testing
Defining the scope of User Acceptance Testing (UAT) is extremely important to ensure your development wraps up in a timely, efficient manner. App testers that join Quality Assurance at the last minute, or provide feedback too late and piecemeal are a developer’s nightmare. Before entering UAT, ask that your client specifies their testing group, and then determine a schedule for feedback and revisions. The best bug tracker for your project is the one that the client will actually use – whether that’s Github or a simply a Google Spreadsheet.
Do: Make sure your User Acceptance Testing process is organized by defining the testing group, bug tracker, and schedule for revisions before starting the testing phase.
7. No Plan for Post-Launch Bugs
Despite your best efforts in UAT, a bug has managed to slip through the cracks, is now live in your app, and the client wants you to fix it. Make sure you have an agreement in place for those times when the bug truly isn’t your fault (e.g. a problem with an existing web-service) so you can be compensated for your work. Even if a bug is your fault, you should have protection from endless fixing after the app has been accepted. It’s perfectly acceptable to offer the client a warranty period limited to 2-4 weeks of free support. Otherwise, set aside a line item for post-launch testing and support fees in your contract.
Do: Make sure you and the client discuss and agree to post-launch support policies, specifying for what period of time. Be thorough about this, and assume any situation you don’t cover is one you’ll be fixing for free.