Building a medical app is a different kind of challenge. It’s not just about making something that works — it’s about making something you can trust. Here’s what I learned building Bolus, an insulin dose calculator for people with diabetes.
What a bolus calculator actually does
In diabetes management, insulin comes in two forms. Basal insulin is the background level — a slow, steady dose that handles your glucose between meals. Bolus insulin is the mealtime dose — a precise amount calculated to cover what you’re about to eat and, if needed, to bring elevated blood glucose back to target.
Calculating a bolus isn’t complicated, but it requires three things: your current blood glucose, how many carbohydrates you’re about to consume, and your personal insulin settings — your insulin-to-carb ratio and your correction factor. Feed those numbers in, and out comes a suggested dose in units of insulin.
People with Type 1 diabetes do this calculation multiple times a day, every day, for their entire lives. It’s something they become expert at — but that doesn’t mean the process can’t be made easier and more reliable.
Why accuracy is non-negotiable
A unit of insulin is not a large amount. In most people, one unit will lower blood glucose by somewhere between 1.5 and 4 mmol/L (or 25–75 mg/dL in US units). Dosing errors — in either direction — have real consequences. Too little insulin, and blood glucose remains elevated. Too much, and you risk hypoglycaemia, which at its worst can cause loss of consciousness or seizures.
This context shaped every decision I made in building Bolus. I couldn’t cut corners on the math. I couldn’t make assumptions about units. I had to be explicit about what the app does and doesn’t do — it’s a calculation aid, not a medical device, and the user’s clinical team sets the parameters it works with.
The research involved
Before writing a line of code, I spent time understanding the domain properly. I read clinical resources on bolus calculation. I looked at how other insulin management tools handle the math and where they make their assumptions explicit. I learned about active insulin time — the concept that insulin taken in the last few hours is still working, and a good calculator needs to account for it to avoid stacking doses.
I also thought carefully about the different settings people use. Insulin-to-carb ratios vary by person and even by time of day. Correction factors vary. Some people have different settings for breakfast versus dinner. The app needed to be flexible enough to handle real-world use without becoming complicated to configure.
Key engineering decisions
I chose to be conservative about rounding. Where rounding is unavoidable, I round in the direction that’s safer for the user rather than the direction that’s mathematically tidy. I also made the calculation transparent — the app shows its working, so users can sanity-check what they’re being suggested rather than blindly trusting a number.
The UI is deliberately minimal. No onboarding flows. No tips or nudges. People who need a bolus calculator already know how bolus calculation works — the app’s job is to make it faster and less error-prone, not to educate them. The faster you can get to a result, the better.
Building Bolus was a lesson in what it means to take software seriously. Every decision had a reason. Every edge case needed a considered response. It’s the kind of project that makes you a more careful developer — not just when you’re building medical tools, but in everything you build afterwards.
Leave a Reply