Diabetes Management App Development Guide for 2023

Konstantin Kalinin

Head of Content

April 11, 2023

When Apple adds a new health sensor, you know wider adoption is coming. That was the case with the heart rate and ECG sensors on Apple Watch. And if you trust Bloomberg, the upcoming model will get noninvasive blood glucose monitoring. No more finger-pricking!

If true, this tech could galvanize the whole space, bringing diabetes tracker app development into the spotlight. Apple will likely ship a new watch model in the fall of 2023. So if you want to build a diabetes management app, there’s plenty of time to prepare.

Whether you plan to take advantage of the rumored technology or want to make use of what’s available, this blog will help you connect the dots.

Top Takeaways:

• Continuous glucose monitoring is the most essential feature of a diabetes management app, and it’s vital to obtain SDK specifications for integration before development.
• Other essential aspects of diabetes management app development include a diary for tracking food, exercises, etc. And so, you should focus on creating engaging and insightful educational content.
• When building a diabetes app, devise it as part of the RPM experience, where healthcare experts control patients’ blood sugar readings at a distance. Remote care is becoming inevitable to reduce costs and optimize processes, and you only need a web platform synced with the app to make that work.

Table of Content:

1. Step #1: Shape Your Diabetes App Idea
2. Step #2: Time to Draw: Prototyping
3. Step #3: Now We Build a Proof of Concept
4. Step #4: Here Comes an MVP
5. Step #5: Iterating before and post the Product Launch
6. Topflight’s Experience in Building a Diabetes Management App

Step #1: Shape Your Diabetes App Idea

What are the odds of you coming up with a business idea of creating a diabetes management app out of the blue? We both know that if you’re reading this blog, you’re either a healthcare professional or a mhealth startup planning to optimize diabetes treatment.

That said, let’s put aside statistics and impressive figures describing this healthcare niche for now and plunge right into diabetes app development steps.

Also Read: Healthcare App Development Guide

Goals

Why are you considering such an app at all? Here’s what comes to mind immediately, and let us know if that resonates with you:

• improve treatment efficiency
• reach patients in remote areas
• serve more patients simultaneously without overtime shifts
• establish stronger connections with patients
• lower administrative costs
• avoid readmissions

After defining the goals, you need to frame them in terms of the ROI potential and prioritize them. Of course, as you go through the ROI goals, you’ll need to ponder potential monetization options. Let’s leave that part out of this guide, as monetization strategies vary profoundly based on your business model.

I can vouch for a SaaS subscription-based model that’s taken over the world, or you can decide that an app will help you reach enough new customers to justify a free or freemium model.

Once the goals are clearly defined, it’s time to closely examine your target audience.

Target audience

Are you targeting people regardless of age, type of diabetes, and condition, or does your app focus on a specific group? I think you’d agree that children with type 1 diabetes, caregivers, senior patients, and pregnant women will all have different expectations from the software. Will your diabetes app cater to providers’ needs too?

So, in short, you’re looking for detailed answers to the question of who will use the app. Understanding their pain points and envisioning how the software could solve them are critical at this step.

By the way, defining the goals and researching the target audience is entirely on you. Of course, a dev shop can help you with competitive research, but without a strong product vision coming from you, it will be useless.

We have a special procedure at Topflight to help you with the tech feasibility discovery (the micro-steps below), and that only works if you come well-prepared.

Critical features

Now it’s time to formulate the main features for your diabetes software. The list can be as long as you like, with its items ranged by priority. Remember that only 1-2 critical features from the list will immediately go into production (see further steps to understand why).

Image credit: App Store, mySugr (all image rights belong to Apple Inc.)

Speaking of critical features, we obviously rule out the most ubiquitous options like authorization, settings, notifications, etc. Instead, we focus on the core functionality, for example:

• AI-driven insights for keeping a balanced, healthy lifestyle
• glucose monitoring (with manual or sensor-based data entry)
• ChatGPT-like chatbot for educating oneself on diabetes
• live consultations
• recognizing food in photos and calculating calories, sugars, etc.
• building a vibrant community with social media-like options
• identifying patterns in a treatment plan for patients based on their behavior

You get the idea, right? By the way, telemedicine (video calls, chat, scheduling) doesn’t have to be the cornerstone of a diabetes app. Using our Telehealth Platform, you can effortlessly implement these features within a reasonable budget.

The reason we postpone focusing on self-evident features like a user profile or sign-in is that they have little impact on the user experience. Besides, they typically require much less effort than critical features and can be realized using ready-made blocks of code.

At this point, it’s best to reach out to a couple of agencies to bounce feature ideas off their heads. Once the list of prioritized features is ready, you can move on to the next stage within step 1.

Technical feasibility

Even envisioning your diabetes management app’s features, you can’t avoid picturing how precisely patients and providers will use the software.

• Do we need to integrate with a medical device (a pump or a smart meter)?
• Does this medical hardware provide an SDK for seamless integration?
• What architecture is ideal for serving x number of patients and further scaling?
• What devices and browsers should the app support?

These are just some of the questions you and your technical partner will need to figure out before going further. At this point, you finally get a better idea of what level of effort will be required to develop the diabetes management app.

Also Read: HIPAA Compliant App Development Guide

As a result, your diabetes management app idea takes shape in terms of:

• list of critical features that solve customers’ pain points and help you reach your business goals
• ideal setup for the app, e.g., a web platform for providers and a smartphone/ smartwatch app for patients syncing with a smart medical sensor
• tech stack approximations

And that wraps up the first step: your business goals are aligned with users’ needs and formalized in features backed by tech discovery. It’s time to add color to your diabetes app.

Step #2: Time to Draw: Prototyping

The next step is prototyping. Not all app development agencies follow this route, but Topflight proves its efficiency practically with every new project. How else can you validate your diabetes management app idea without spending a fortune and potentially hitting a dead end?

The design costs associated with our rapid prototyping practice are a fraction of the total coding/testing/etc. Costs. At the same time, with a prototype, we can collect users’ feedback and iterate without writing a line of code.

Anyways, to give you a better idea of how that works:

• identify main user journeys
• create low-res wireframes
• confirm with the client’s vision
• design hi-fi wireframes for 10 critical app screens or so
• put together an interactive click-through prototype
• share the prototype with test users
• analyze feedback and iterate if necessary

That’s just a glimpse of how to design a diabetes-tracking app using rapid prototyping. To reiterate, we follow this practice to:

• spare the development budget
• help you get buy-in from investors
• get the first validation of your idea from customers
• speed up time to market (changes in coding take forever compared to designing)

Step #3: Now We Build a Proof of Concept

Ready for a trade secret? No one builds Uber Health in one go. Yeah, I know: it’s pretty simple. Yet many founders get so excited seeing their app idea take shape that they keep piling up features and delaying the release. That’s a no-no in our book, especially for something as complicated as creating a diabetes tracker app.

We stick by our Vision-to-Traction System (VTS), which has proven to deliver successful healthcare products for our partners. And according to the VTS, you should have a demo within 2-3 months after the prototype is ready.

This demo is a proof of concept that displays the product’s advantages through its key features. And while a PoC is not good enough to distribute it publicly, we can use it to gain valuable feedback from stakeholders and test users. Plus, it’s a perfect tool for raising capital.

Here are a few things you need to consider when working on a proof of concept:

• no code or low code can be optimal for creating a more complete demo product
• consider the cost of switching to a custom architecture from no code in the future
• if the app uses AI, focus on these features (recommendations, chat, or whatever)

When a proof of concept is ready, we pilot it with “test” customers (including providers and patients here) and show it to investors to validate the idea and raise more money.

Step #4: Here Comes an MVP

The next step of the diabetes tracker development is turning the PoC into a releasable product. Obviously, it can’t be a 100% complete product — just like Uber couldn’t release Uber Health (in its current state) in 2018. As you know, successful apps evolve over time, and so compromises are inevitable.

Also Read: MVP App Development Guide

That’s why as the next step, we focus on developing a minimum viable product (MVP), which we call MDP — minimum delightful product. The idea is to include enough exciting and valuable features to generate real traction without postponing the product launch until market conditions change.

Development process high-level overview

The development process pretty much stays the same, i.e., an agile team keeps shaping the app from different angles. Who takes part in development?

• you, as the product owner

Responsibilities: keep tabs on the progress, and provide timely feedback. The team will come back with suggestions of all sorts, including monetization and mobile marketing strategies.

• product manager

Responsible for updating a product backlog and preserving your vision within the dev team while deciding on the next cornerstone features to implement.

• project manager

Responsibilities: manage the development team consisting of designers, coders, testers, DevOps engineers, etc.

• team members: designers, programmers, QA and DevOps engineers, etc.

The agile development approach implies that the development process is flexible and easily adaptable to how customers percept early versions of the product. Here’s how that looks in practice:

• the team decides what they are building for the next two weeks (a sprint)
• after each sprint, they analyze the progress and remove roadblocks
• this process continues until we arrive at a releasable app candidate

This diabetes management development process is very fluid. While developers put in lines of code, designers work on remaining app screens, and QA engineers test intermediary app versions. I mean, you don’t need to wait after two weeks to see the progress — testing is included.

At the same time, DevOps engineers set up an automated pipeline for testing and assembling new app builds. And the beauty of all that is that each team member contributes to the whole process as needed.

Also Read: DevOps Implementation Plan: A Complete Guide

For example, there’s no need to keep a DevOps developer on a project full-time; the same applies to designers and product/project managers.

What should be top of your mind while creating a diabetes management app?

Use tried-and-true off-the-shelf components

As always, no need to reinvent the wheel. For example, if you want to add an intelligent conversational chatbot to educate patients, why waste time devising your own ML models. OpenAI and similar companies offer convenient APIs making a ChatGPT-like bot readily available for the app.

The same goes for telemedicine, scheduling, and other functionality. Time to market and development costs become more manageable with these ready-made solutions.

Design for people, not use cases

Of course, that’s more of the designers’ responsibility, but you should be mindful of that too. What do I mean? Sometimes, it’s easier to give an example. Here’s one:

Patients may sometimes do the task (take a pill, make an injection, take a glucose reading from a non-integrated sensor) and not track that inside our diabetes app. Provide them a micro UX/UI experience to confirm they already did that, no matter when, etc. — just get out of the way and keep helping them form these healthy habits, even if they sometimes skip to input info into the app.

Another example: an AI engine analyzes the patient’s behavior and suggests simple steps based on how often they interact with the app: one healthy habit at a time. Yet another example: AI notices that the user checks in the app 15-30 minutes after the timer goes off. Why not ask them to reschedule for this time automatically with a simple tap?

Here’s another tiny example of a user-centric design (just to let you know how many things developers need to consider). What happens if customers accidentally turn off notifications for your diabetes app? Does the app check automatically (at set intervals or at launch) if notifications are turned on and remind/explain to patients how to turn them on?

Take advantage of the mobile platform capabilities

Diabetes management apps are all about tracking, right? Users must monitor their blood glucose level, calories, exercises, etc. So why not let them add widgets to the lock and home screens (and educate how to use them) to simplify tracking their vitals?

Another example would be using Swift charts to enable out-of-the-box accessibility options allowing patients with poor eyesight to listen to their readings.

Integration with smart meters

Do you plan to work with a single custom-made device? In this case, the integration will be relatively simple. What if you want to support existing meters? Do they have libraries and SDKs to integrate with smartphones?

Truth be told, these questions should be answered by your dev team during the first step as they assess the project’s technical feasibility. However, thinking through an intuitive and engaging UI that takes advantage of all meter’s capabilities can still be challenging.

And we absolutely have to get this right because continuous glucose monitoring (CGM) is often the key element of any diabetes-tracking app.

Think through providers’ experience

A web portal for providers built right turns a diabetes app into part of a remote patient monitoring (RPM) platform, allowing for cost savings and other benefits.

Interoperability

At some point, your diabetes tracking app must integrate with EHRs. To simplify data sharing, use industry standards, for example, SMART on FHIR, an HL7 standard for securely syncing health data.

Another point worth considering is integrations with Apple Health, Google Fit, and similar services. You mean even consider integrating with popular calorie counting and/or fitness apps to automate data entry as much as possible.

Gamification

Introducing goals, milestones, achievements, leaderboards, and other gamified user experiences helps patients develop critical habits painlessly. You may consider adding mini-games with virtual characters if the target audience is kids.

Education is also a huge part of promoting a healthy lifestyle. It’s best when the app combines passive and active learning. Let’s say patients learn about the necessity to track or perform some action daily – now show them how to set up a timer or reminder easily.

In addition to educating customers on general topics like hypoglycemia and hyperglycemia, include situation-specific materials to foster better blood glucose self-management.

This high rating caused a lot of sweat, and that’s an ongoing process

Image Credit: App Store, user review for One Drop (all image rights belong to Apple Inc.)

Step #5: Iterating before and post the Product Launch

Sooner or later, you get to the point where you’re comfortable releasing the app. From that point on, you’re in maintenance mode.

To be frank, step 5 — maintenance — resembles step 4. It’s the same cycle of polishing app features and removing awkward bugs on rare smartphone configurations. The only difference is you shift your focus a little toward app monitoring this time.

• user engagement tracking (like user behavior tracking on websites)
• issues monitoring (downtime, bugs, sync issues — minor stuff tends to happen even for the most successful product at times)
• user feedback management
• mobile OS- and third-party libraries-caused updates

Fortunately, plenty of automatic tools exist to make these tasks less stressful and make your app a successful product.

Topflight’s Experience in Building a Diabetes Management App

Before we wrap up, let me just mention that Topflight is happy to have taken part in creating a diabetes tracker app that pulls health data from an intelligent sensor. The app served as an extension to an RPM platform to optimize workflows and costs for diabetes treatment.

The solution is being piloted on a population of over 100k patients.

If you have questions about creating a diabetes mobile app or a web system for physicians, get in touch today.