Islet

islet has over 600 tests. casectl has 313. cable-club has 19 accuracy tests that compare framebuffer output pixel-by-pixel against a reference emulator. These are different projects in different languages solving different problems, and they all test heavily. This is not an accident. The principle If you cannot verify a claim automatically, you do not actually know if it is true. You think it works. You believe it works. You tested it manually once and it seemed fine. None of that counts. What counts is a command you can run that tells you, definitively, whether the system does what it is supposed to do. ...

On Friday morning, islet had 766 tests and no concept of food components, rate limiting, or offline caching. By Sunday evening it had 1,750 tests, schema v8, a tiered rate limiter, photo-based meal estimation, a component meal architecture, a sync infrastructure, an iOS SwiftData cache, an alert detection engine, and a time-in-range dashboard showing 51.8% TIR across 14,000 CGM entries. One session. Safety note: islet is a personal project and is not medical advice. It does not make dosing decisions. ...

The foundation is solid. The daemon runs, the API accepts data, the iOS app logs meals and shows predictions. But "it works" is not the same as "it works well." The next phase is six focused improvements that take islet from a system that functions to one that feels right. The shape of the work Six plans, ordered by dependency. Some are small fixes to obvious gaps. Some are structural changes that touch the database schema, the API, and the iOS app in a single pass. All of them come from the same source: using the system every day and noticing where it falls short. ...

On February 15th, islet was a name and some planning documents. By March 7th, it was a daemon running on a Raspberry Pi, a Flask API accepting data from two phones, a glucose prediction engine, an iOS companion app with eleven screens, an Android follower app, a food template system, and a test suite with over 600 tests. This is not a story about moving fast. It is a story about what happens when you have already done the thinking. ...

Until this week, glucore could describe what had happened. IOB and COB curves modelled insulin and carbs in progress. Trend analysis showed which direction glucose was heading. But it could not answer the question that actually matters: where will glucose be in an hour? The prediction problem Predicting blood glucose is harder than it looks. The obvious approach — extrapolate the current trend — fails quickly. A falling trend after a meal correction does not mean glucose will keep falling at the same rate. Insulin activity peaks and then decays. Carbs absorb at different speeds depending on composition. Momentum from a rapid rise can persist for minutes after the underlying cause has passed. ...

The iOS app is for the person wearing the sensor. The Android app is for everyone else. My partner checks my glucose when I am asleep or driving. She does not need meal logging, prediction charts, or food templates. She needs a number, a trend arrow, and a colour that tells her whether to worry. Different user, different app islet’s iOS companion is a tool for managing diabetes — food logging, AI-assisted carb estimation, treatment input, prediction overlays. It is complex because the problem is complex. But a follower does not need any of that. A follower needs: ...

The hardest part of carbohydrate counting is not the maths. It is the data. Supermarket food has labels. Restaurant food has menus with calorie counts. But the pasty from the bakery on your high street — the one you have been buying for years — has nothing. You guess. You are always wrong. The problem islet has a food template system. When you log a meal, it checks the description against a library of known foods and returns an instant carbohydrate estimate without needing an AI call. The library covers packaged foods with published nutritional data — Tunnock’s Caramel Wafers, Penguin bars, sliced bread by brand and thickness. ...

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. ...