Two changes that have nothing in common except timing. On Friday, islet gained per-user SQLite databases for multi-user data isolation. On Saturday, the iOS food logger gained local food templates for instant meal estimation without an API call. One is about infrastructure. The other is about speed. Both matter more than they look. Safety note: islet is a personal project and is not medical advice. It does not make dosing decisions. The single-user assumption Until Friday, islet had one SQLite database. One file. One user. Every glucose reading, every meal, every treatment went into the same tables. That was fine when the only user was the person who built it. ...

On Wednesday evening, the islet web UI got a navigation overhaul: hash routing, a floating action button, a Canvas 2D glucose chart, and dedicated pages for food and treatment input. Eighteen hours later, the iOS app got the same overhaul: TabView, a floating action button, a SwiftUI Charts glucose chart, and sheet modals for input. Same design. Same information architecture. Not a single line of shared code. Safety note: islet is a personal project and is not medical advice. It does not make dosing decisions. ...

The islet iOS app shipped a day ago with four screens. It already felt like too many. The food logger had five stacked tag pickers, a chat interface hidden behind a button, and a meal history on a separate screen. Every meal entry meant navigating in, filling out a form that looked like a medical questionnaire, then navigating back. The data was right. The experience was wrong. Safety note: islet is a personal project and is not medical advice. It does not make dosing decisions. All carb estimates are informational only. ...

For nine days, islet has lived in a terminal. The daemon runs on a Raspberry Pi, the analytics engine crunches numbers in the background, the API accepts uploads — all invisible unless you know the right curl command. Logging a meal meant SSH and a CLI. That works at a desk. It does not work holding a fork. Safety note: islet is a personal project and is not medical advice. It does not make dosing decisions. PCU values are informational only and must not be used as dosing advice. ...

On February 15th, islet was a Python script that polled Nightscout every 60 seconds and stored the results in SQLite. Nine days and 86 commits later, it runs as a self-hosted platform: its own ingest API, analytics engine, relay system, and a native iOS app on my phone. Nightscout polling is off. The only remaining dependency is a relay for the second phone. Safety note: islet is a personal project and is not medical advice. It does not make dosing decisions. PCU values are informational only and must not be used as dosing advice. ...

For the first two weeks, islet was a parasite. It polled Nightscout every sixty seconds, pulled down whatever was new, and stored it in SQLite. Nightscout did the hard work of receiving data from CGM apps. islet just copied it. That dependency was always temporary. Why Nightscout had to go Nightscout is a good project. It solved CGM data sharing when nobody else would. But as a dependency inside islet, it created three problems: ...

For eight days, islet has been the primary ingestion path. Tonight it became the only one. Nightscout polling is off. Both phones POST directly to a Raspberry Pi in the next room, and the system does not care. That sounds undramatic because it should be. The entire point of the last eight days was to make this moment boring. The dependency that was hard to see Nightscout was never just a database. It was the implicit trust boundary for every data flow in the system. Sensor readings went from phone to Nightscout to islet. Treatments went the same path. Every piece of data arrived through someone else’s API, on someone else’s schedule. ...

Most migration plans look clean in architecture diagrams. One box becomes another box, one arrow moves, and the system is “simpler” afterwards. In practice, the shape of the arrows matters more than the boxes. For islet, Phase 3 looked simple on paper: stop depending on Nightscout polling, accept uploads directly, keep local storage as the source of truth, and treat upstream relay as optional safety. The target was straightforward: Libre sensor -> phone app -> islet ingest API -> SQLite -> analytics. ...

There's a strong temptation, when you know what you want to build, to just start building it. Open an editor, create a file, write the first function. You'll figure out the rest as you go. I’ve done that plenty of times. It works until it doesn’t. The problems tend to arrive around the third or fourth decision that depends on an earlier one you didn’t think through. By then you’re committed and the cost of changing direction is no longer zero. ...