Why I Built SweetLife

I'm Antonio. SweetLife isn't a company or a startup. It's an app I built for my partner, who has Type 1 diabetes, because the apps she was already using weren't good enough.

What "living it" means when it isn't your body

I don't have Type 1. I've still lost count of the nights a sensor alarm has pulled me out of sleep. I've sat with her through lows and waited out the fifteen minutes before a number starts climbing again. I've watched insulin go in overnight because the sensor asked for it, then lain there awake afterwards watching the graph to be sure it worked.

That's the part people outside it don't see. Diabetes isn't something that happens between appointments. It runs all night, every night, and it doesn't care that you both have work in the morning. You don't get to opt out of it because it isn't your pancreas.

So I'm not the patient, and I won't pretend to be. But I'm in it, and everything here was built from inside it rather than from a spec.

When I wrote the App Store description, I worried that calling myself someone who "lives it" was claiming a bit of something that isn't mine. I asked her about it. She told me to keep it.

Three apps, one condition

Her phone had a small collection of them. One existed purely to put her glucose number on the home screen, so she could glance at it without opening anything. Another was a logbook, where meals and doses got typed in by hand. A third was the manufacturer's own CGM app — accurate, essential, and about as inviting as hospital software.

Every one of them did its single job perfectly well. None of them knew the others existed. The reading sat in one place, the meal that caused it in another, and the insulin that answered it somewhere else again. You'd have to hold all three in your head to see what actually happened.

Diabetes isn't separate chores

That's the part that bothered me. A high at 4pm isn't one event; it's lunch, and the dose that covered it, and whether she'd walked anywhere, and what her blood sugar was doing beforehand. The condition is continuous. The tools treated it like a set of unrelated errands, and left the joining-up to the person least able to spare the attention.

The other thing I noticed: the more clinically accurate an app was, the more it looked like it was designed for a filing cabinet. Charts in grey. Numbers in tables. Nothing that acknowledged a person opens this thing eight times a day, sometimes at three in the morning, sometimes after a number that's ruined their afternoon.

The post that decided it

What turned the irritation into actually building something was a post I came across from a mother whose young child has Type 1. She was listing the apps she had to run — one for this, one for that, each handling a single simple thing — and it struck me as ridiculous that this is what people are left to cobble together.

So it wasn't only us. A family gets handed a condition to manage and a pile of half-apps to manage it with. That seemed worth fixing.

What I wanted instead

One app holding the whole picture. Readings, insulin, meals, exercise. A bolus calculator that shows its working. Patterns pulled out of her own data instead of generic advice.

And her CGM data arriving on its own, rather than asking her to retype numbers her sensor already knew. She wears a Medtronic pump with their sensor, which is why SweetLife talks to Medtronic CareLink directly. It is the hardest part of the app to build and the hardest to keep working, and it exists for the plainest reason there is: it is what she uses. Medtronic tends to be an afterthought in apps like this. Here it was the starting point.

Starting point, not boundary. Dexcom and FreeStyle Libre readings come in through Apple Health, and nothing in the app assumes a pump — injections, pens and pumps all work the same way. The point was never to build a Medtronic app. It was to build the app I could not find, and hers happened to be the hardest case to solve first.

And something that looks as little like a clinic as I could manage. That was a goal, not a finishing touch. A high number is information about a few hours, not a verdict on the person, and the difference between an app someone opens and one they avoid is mostly a matter of how it makes them feel to open it.

The mascot is a juice box called Chug. That is not a branding exercise. Chugging juice is what a low actually looks like at three in the morning.

Built for one person first

The first two things I built were a logbook and a chart, because those were the jobs being done worst.

After that, every feature had to pass one test: would she use it on a bad day? Not whether it demos well, or rounds out a feature list. Whether it survives contact with someone who's tired, out of range, and not in the mood to be managed by software.

She still uses every build before anyone else does. Plenty of things haven't survived that.

Built for her first doesn't mean built only for her. One person is a good way to keep an app honest; it's a terrible way to decide what everyone else needs.

What isn't here yet

The widget — the very thing one of those three apps existed to do — isn't built. It's at the top of my list, and I'd rather say so plainly than let a feature list imply otherwise.

SweetLife is also a tracking tool, not a medical device. It doesn't diagnose anything, and it isn't a substitute for your care team. The bolus calculator is a calculator: it does arithmetic with the settings you and your doctor agreed on.

Who it's for

Type 1 or Type 2, pump or injections, Medtronic or Dexcom or Libre or a meter and a notebook. Anyone doing this every day — and anyone doing it alongside someone they love, which is the seat I sit in. The core is free and stays free — logging, CGM sync, family sharing, Chug, the education hub. Plus exists for people who want deeper analysis, and it funds the rest.

If something in the app is wrong, missing, or annoying, I'm the person who reads the email. [email protected].