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

I am a Welsh speaker. Not someone who did a Duolingo streak — I am wholly fluent, and it is my language of choice. When I build software, Welsh goes in from the start — not as a translation layer bolted on later, but as a first-class citizen. The thread Every major project I work on has a Welsh dimension. Not because I set out to build Welsh software, but because I set out to build software that works for me, and I happen to be Welsh. ...

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

The screen cracked in a way that made the laptop useless as a laptop but perfectly functional as a computer. The M2 chip, 16GB of RAM, and 512GB of storage still worked. Throwing it away or paying for a screen replacement both seemed wrong. So it became a server. The hardware MacBook Pro M2, 2022. The display is physically intact but the LCD panel has internal damage — a spreading dark region that covers about 60% of the screen. Enough to make it unusable for direct interaction. Not enough to trigger a warranty claim (it was out of warranty anyway). ...

I run my own email server. On a Raspberry Pi. In my house. It sends and receives real email. People reply to it. It has not lost a message. I would not recommend it to most people. The approach The fundamental problem with self-hosting email is that the internet assumes you are a spammer until proven otherwise. Residential IP addresses have no reputation. ISPs block the ports you need. Even with every DNS record configured perfectly, the big providers will silently drop your messages for weeks until they decide you are probably legitimate. ...

Every project had its own deployment script. islet had deploy_pi.sh. gwefan had a bespoke scp chain. ira had nothing. Each script did roughly the same thing — build, upload, restart — but each did it differently enough that copying between projects meant editing half the lines. On Saturday, all three projects switched to a single shared toolkit. The duplication problem islet’s deploy script was the most mature. It rsynced Python source and config files to the Pi, restarted two systemd services, ran a smoke test against the health endpoint, and printed a status summary. It worked well. It had also been rewritten twice as the project grew, and the third version was 80 lines of bash that nobody would want to port to another project. ...

ira started as a telemetry display. Connect to iRacing's shared memory, show speed and RPM, log to CSV. Useful but narrow. On Saturday it gained race guides, session registrations, owned content detection, and a test suite. Seven commits. One day. A different kind of application. What ira was A C program that did three things well: Read telemetry from iRacing’s shared memory at 60Hz Log that telemetry to CSV for post-session analysis Launch helper applications automatically when a session starts All local. No network calls. No authentication. The iRacing SDK gives you shared memory for free, and everything ira did was built on that foundation. ...