Hybrid apps in healthcare, part II - How to make the decision

Hybrid apps in healthcare - How to make the decision 

Codepole recently held a webinar for Swiss Healthcare Startups in Switzerland. The webinar specifically was focused on shedding light on hybrid mobile applications, its suitability for healthcare apps, along with decision factors and how to approach such a decision. In this blog post, about decision making approach, we will reiterate on what was presented at the webinar with also a bit more depth to the content. This is the second blog post in the series of two - you can find part I here.

Quick repetition on previous blog post

In part I we delved deeper into what factors you should consider when considering if a hybrid approach is a good option or not. In that blog post, we shed some light on factors such as who your users are, the complexity of your product, if it is to use device functionality, platform consistency, security, state of your company (budget, time, team set-up, etc.), and other factors (partners, payors, amongst others). 

However, with part I, we don’t really go into any depth on how to actually approach a decision. Alright, now we have somewhat a good understanding of the factors I should consider, but what else?

When is it relevant for me to enter a decision phase?

We mentioned it in part I, but it’s worth mentioning again - a technical stack, or technical approach should always be reviewed, continuously. It’s something that grows with you, the company, and ideally the technology should actually lie somewhat 6-12 months ahead of the needs of the company. With that, it also means that you can enter a decision phase on the technical stack at any point in time.

Most natural, it occurs before the product is built in a production environment. This is the most natural state to decide on native, hybrid, or web as a technical approach. However, I’ve myself also been in situations where this decision has been reversed with a mature product as well. It’s typically been based on cost, the requirements put on the product, or speed needed.

Approaches to decision making

In the webinar, we concretely shed some light on three approaches. There are of course 100’s of decision making approaches or templates, but we made a pragmatic approach for the webinar and summed up 3 that we believe are strong and that have been used by ourselves at times.

Purpose-driven decision making

Purpose-driven decision making, which could also be called framework driven decision making, simply means that you structure the decision in some sort of qualification or tree structure. There are a lot of them out there, but we summed up one that we think contains the more relevant parts of this particular decision, as well as being anchored in our experience. You would go through the decision tree and very consciously decide for the approach that you end up receiving. 

As an example, let’s say that I want to create an app that allows users to receive healthcare-related news that are individually tailored to each user. In this case, starting with step 1, I would not require any hardware functionalities. Moving along the tree, it asks me if there would be any content difference between my existing website and a potential app - i.e. would I have the same content everywhere. If no - i.e. I don’t require different content on mobile vs web - the recommendation is to bet on a web application. If yes, I move along the tree to another question. 

This might seem very simplistic, however, we believe that such an approach may allow for easier decision making in the beginning, as well as a better continuous assessment. 

Overall, this approach is mostly recommended for companies that do not yet have an application, or perhaps only a webpage. 

Validation-driven decision making

This decision making approach suits healthcare companies well. Essentially, you build your product hybrid-first. This ensures cost effectiveness, speed, and flexibility, that we in the healthcare space often require. Before building, however, you set some sort of objective. It could be for example #paying customers, X% NPS, X/10 in satisfaction score, or something else. It could also be smaller, more specific to a single feature, for example X% conversation between funnel step 3 and 4, or #sign-ups to a specific feature.

Once the app is built, and you’ve reached your objective - you’ve then validated, cheaply and quickly, that there is some traction there. Now is the time to build it natively.

This methodology is recommended for organisations that are deeply validation-driven, or organisations that want to be very cost efficient before putting more money & time into products or features. With this methodology, you at least restrict the more expensive native approach to be built after validation occurs.

Threshold-driven decision making

This is implicitly the most used decision making approach, even if not specific to bigger questions such as hybrid or native. This methodology is similar to the validation-driven one, but you specifically have a threshold for all areas of your product (think FAQ, homepage, registration, core feature, nice-to-have feature, etc). Each area of your product that surpasses the threshold is re-written from hybrid to native. 

This method is very powerful as you can get features and functionality out quickly to users. However, only the most impactful, most used, or most critical areas of the product are re-written to native. By using this approach, you restrict the money and time put into the app until actual criticality is hit.

In the image below, you can see an example formula for a threshold. In this case, I would score the 4 parameters (number of users, impact of product/feature/product area, customer support complaints, cost) from 1-10 for each product/feature/product area(s). The product/feature/product area(s) that surpass the threshold (x) would be candidates to re-write.

A similar methodology (falls in a similar category) is to simply prioritise re-writing hybrid to native of the product/features/product area(s) in the same backlog as the rest of the product work. It could also be a separate backlog from the regular backlog that is chipped away at a fixed interval (% of time, or #items quarter). This is, similarly to above, a good methodology to ensure that you build things cheaply and with speed, and then consciously prioritise what is to be re-written to native. Our recommendation is to sue a prioritisation framework such as RICE (Reach, Impact, Confidence, Effort).

Ending note

As with almost all technical decisions, they mostly come back to

• Time. Can we ship it fast(er)? 
• Budget. Can we ship it cheap(er)?
• Scope. Can we ship all the things we want to ship?

It is important. Based on my experience, I’ve come to realise that we’re all playing an infinite game. There is often not a right or wrong way to move ahead. This particular decision might save you a lot of money, time, and flexibility of the product. But it might also put you in a situation of limitations, overhead (re-writing code, or writing code you don’t actually need). That’s why we’re big proponents of making conscious decisions that are well thought not only before you have an application, but continuously throughout your journey. 

A video extract of our webinar where our explorer Gustaf explains the decision making approach for healthcare applications can be found here.

Feel free to reach out if there are any questions or you would like to get access to the full webinar recording,

Robert