World Diabetes Day is on 14 November, and the 2026 theme is early action on diabetes: earlier diagnosis, better access to care and less stigma. Software can help with all three, but only if it fits into the daily life of the people using it. This post covers what a diabetes care app needs to do for patients and for the clinicians who look after them.

The scale is large. The International Diabetes Federation estimates that about 589 million adults aged 20 to 79 live with diabetes, around 1 in 9, and that roughly 252 million of them do not know it yet.

Start with daily life, not features

Living with diabetes means many small decisions every day: what to eat, when to check, whether to take a dose, what to do about a low at night. An app that adds work to that day gets deleted. An app that removes work gets used.

So the first question is not "what can we build?" but "what does a normal Tuesday look like for this person, and which part of it can we make easier?"

  • Logging in seconds. Glucose, meals, medication and activity should take a tap or two. Sensible defaults and "same as yesterday" save more time than any clever feature.
  • Automatic data. Readings from continuous glucose monitors (CGMs) and meters should arrive by themselves, so nobody copies numbers by hand.
  • Clear trends, not raw numbers. Time in range, daily patterns and plain-language summaries are easier to act on than a long list of readings.
  • Gentle reminders. Medication, checks and appointments, with quiet hours and the option to snooze. Too many alerts and people turn them all off.
  • Sharing on their terms. With a clinician, a parent or a carer, and easy to switch off again.
  • Works for everyone. Diabetes can affect eyesight, so large text, strong contrast and screen reader support matter. So do offline use and more than one language.

What clinicians need

  • A summary they can read in a minute. Standard views such as the ambulatory glucose profile (AGP) and time in range are familiar and quick to scan. International consensus suggests that for many adults more than 70% of readings should sit between 70 and 180 mg/dL (3.9 to 10.0 mmol/L), but targets are always set per patient by their care team, so the app should let the clinic set them.
  • Exceptions first. A list of patients with frequent lows or rising averages is more useful than every reading from every patient.
  • Data in their own system. Clinicians do not want another login. Sending readings and reports to the EHR through FHIR fits their day far better. We wrote about this in Healthcare data should not stay locked in separate systems.
  • Context. A note that says "ill with flu" or "started a new job with night shifts" explains a week of readings better than a chart alone.

Where the data comes from

  1. Phone health platforms. Apple HealthKit on iPhone and Health Connect on Android collect data from many devices and apps, with the user's permission.
  2. Device makers' platforms. Some CGM manufacturers offer developer programmes with approved access to their data. Access, terms and regions differ, so check early.
  3. Bluetooth meters. Many meters use the standard Bluetooth Glucose Profile, which an app can read directly.

Whichever route you use, plan for the messy parts: gaps when a sensor is changed, duplicate readings from two sources, time zones, and units. Some countries use mg/dL and others mmol/L, and mixing them up is dangerous.

Privacy and regulation

Health data is among the most sensitive data there is. Under GDPR it is a special category, and in the US HIPAA applies when you work with healthcare providers or insurers. At a minimum: collect only what you need, encrypt it in transit and at rest, ask for clear consent, keep an audit log of who saw what, and make deleting an account actually delete the data.

Regulation is the decision to make early. An app that logs and displays data is usually treated as lower risk. An app that calculates insulin doses or recommends treatment is likely to be regulated as a medical device, by the FDA in the US and under the Medical Device Regulation in the EU. That changes how you design, test and document the software, and how long it takes to launch. Get regulatory advice before you build that feature, not after.

A sensible first version


  1. Pick one group. For example adults with type 2 diabetes on tablets, or parents of children with type 1. Their needs are very different.
  2. Build the core well. Fast logging, device import, clear trends, reminders and a report the patient can share with their clinic.
  3. Test from week one with a few patients and at least one clinician, and keep testing.
  4. Measure what matters. How many days a week people log, how many keep using the app after a month, and how much time clinicians save in review.

How Develenza can help

We design and build healthcare apps and the integrations behind them, from device data and FHIR to clinician dashboards, with privacy built in from the start. If you are planning a diabetes or chronic care product, start your project or contact us and we will help you scope a first version that patients will actually keep using.

Sources

  • FHIR
  • Diabetes
  • Mobile Health
  • CGM
  • Patient Apps
Written by the Develenza team

Designers, developers and marketers who build websites, apps and software for growing businesses.

About us