"Now you're speaking my language!" - How to talk to an app developer about your research app

This article originally ran on April 6, 2018 on the Duke Mobile App Gateway for Digital Health website. It was authored by Katie D. McMillan, MPH, Marissa Stroo, MA and Kristine Glauber, PhD, employees of Duke University and Duke University Healthcare System.

Increasingly mobile apps are putting healthcare research directly into the hands of patients. Tools like Apple's ResearchKit, an open-source framework for developing apps for medical research, and FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") which enables health data to be shared quickly and efficiently between applications and systems are making it easier to engage patients and participants directly in research using mobile app technology.

If you're considering incorporating an app into your research, you've got a few options for development:

(1) Depending on the types of data you plan to collect you may want to try Medable's Axon, the DIY app development software that seamlessly integrates with Apple's ResearchKit. The Duke Mobile App Gateway (aka The MAG) has negotiated a license rate specially for Duke researchers. Request a consultation with our team to find out if Medable is right for you!

(2) Your other option includes contracting with a custom app development vendor to have them build the app for you. If you decide to go this route, we've come up with a few key questions to help you find the right vendor to fit your project needs.

WHERE CAN I FIND YOUR PREVIOUSLY DEVELOPED APPS?

Your prospective developer should be willing and able to show you a portfolio of apps they have developed for other clients. You want to ensure that your developer is experienced, and that their style fits with what you're looking for. Another good rule of thumb is to request a reference list of previous or ongoing clients with whom you may discuss their experiences working with the company.

HAVE YOU DEVELOPED APPS FOR RESEARCH BEFORE?

The research world operates differently from the commercial product world. Try to find a developer who has worked on research apps in the past and who knows the regulatory environment in which your app will live. You may also want to look for developers who have worked with Duke previously, as they may be aware of the requirements for working with Duke. The MAG also maintains a list of vendors who have been “pre-certified” by Duke for app development. You do not have to use one of these developers, but these developers have undergone trainings on Duke security requirements and have been vetted by the MAG.

WHICH PLATFORM(S) ARE YOU COMFORTABLE DEVELOPING FOR?

Apple and Android each have their own norms for design, user experience, and functionality. Ensure that your developer has experience and expertise developing on the operating system(s) that you plan to use for your study. You should also consider your particular study population and if they are inclined to favor iPhones or Androids before choosing your development direction.

If you plan to make your app available on both, you will likely need two different apps, which will affect your budget. Building on both operating systems can mean at least double the costs. There are some products like PhoneGap and Xamarin that can be used to “code once and share twice.” Be sure to ask the developer about this approach and if they has experience in that area.

HOW WILL YOU ESTIMATE COSTS AND SCHEDULE FOR MY PROJECT?

According to a review done in 2017 by SavvyApps the cost for an app can range from $50,000 to $2,500,000. These costs vary based on the type of app and the complexity. 

If you are getting a quote to use in a grant application be sure to ask the developer for a copy of the quote or other form of documentation to include in the grant application as an appendix. This can strengthen your budget justification and your project timeline projections.  

WHAT PRODUCT MANAGEMENT PROCESS DO YOU USE?

There are two main schools of thought for software development: waterfall and agile. Waterfall is a traditional approach of determining all features up front, creating a development plan and building to those specifications. Agile is a value-based approach. Each company will develop a cadence, but teams typically work in sprints ranging from a week to 2 weeks on average and constantly evaluate the highest value features and deliver an updated build at the end of each sprint. Typically it comes down to a company’s culture and what fits your project's needs. Agile requires (and benefits from) a lot of customer interaction, therefore, you will need someone on your team dedicated to participating in discussions around features as well as testing the app and providing feedback to the design and development team.

ARE YOU GOING TO DO ANY BETA OR PILOT TESTING OR CONDUCT USER-FEEDBACK SESSIONS?

Getting feedback from your target audience is important. If something doesn’t work, users will give up and might never return. You don’t want to risk alienating your participants because of a poor interface choice that could have been easily identified and changed early in your development process. Plan on getting feedback throughout the process if you can. You may want to include a budget item for this process. There are a lot of strategies, but at the end of the day it is about how you think you can best get meaningful input. It could be that you pay some testers, or that you conduct interviews and want to compensate them for their time, you may also just have a focus group with pizza. If you want help creating a user testing plan, schedule a consult with the MAG.

WHO WILL OWN THE APP?

There are many ways to structure a software development agreement. You should discuss who will own the IP behind the concept of the app as well as who will own the code for the app. The Duke Office of Licensing and Ventures can help you to determine how to best protect your intellectual property. Occasionally, development companies will accept an equity stake to reduce the cost of the development but this is only a fit if the app has plans to commercialize after the research phase and should also be discussed with OLV.

WILL YOU MAINTAIN THE APP POST-LAUNCH?

This is a key budget item that most research team aren’t aware of up front. New OS versions are regularly released, and you want to ensure that your app will continue to work on the latest version available for the life of your study. If your developers will also be managing the backend servers for your app then you need to account for regular security patches and updates to those as well. If your developer is not going to maintain the app post-launch then you need to make a plan for the on-going support of your app, and budget for that appropriately. Duke Health Technology Solutions (DHTS) can maintain an app at Duke but that support will also require budget and staff allocation. Consider your options prior to signing a contract.*