A lot of the last few days looked like development work in the least dramatic sense.
Not new surfaces so much as less duplication underneath. Not more activity from the product, but less unnecessary work.
That ended up touching a few parts of Caligo Relief at once: how sessions are handled, how rows and views decide what actually needs to update, and how the widget behaves when something changes.
Similar flows should not need separate systems
One thread of work was reducing the distance between activity types that were starting to behave more similarly than the code around them suggested.
If two parts of the product are both tracking a live session, carrying progress forward, and deciding what belongs to the current attempt, they should not keep drifting into separate systems just because they started from different features.
So a lot of recent work has been about bringing those paths closer together. Less duplicated logic. Fewer special cases. A clearer sense of what belongs to the current context and what should happen when the day shifts underneath it.
This kind of work is easy to miss from the outside, but it matters. When the underlying model is calmer, the product gets easier to change without introducing new confusion.
The interface should update with more restraint
I have also been tightening how the app decides what actually needs to re-render.
As a product grows, it is easy for screens to start reacting too broadly. One small change can wake up much more of the interface than necessary. That may not look dramatic at first, but it creates a low, constant tax on responsiveness.
So part of the work has been moving toward smaller render states, clearer selectors, and more stable cached values for the expensive parts. In practice, the goal is simple: let the changing parts change, and let the stable parts stay still.
That sounds technical, but the reason is not technical vanity. A calmer render path usually means a calmer product.
Widgets should feel live without constantly waking the system
The widget work has been similar.
A widget needs to feel current, but it also has to earn every reload. If it asks the system to wake up too often, that cost shows up somewhere else: more churn, more battery use, more background activity for very little user value.
So some of the recent work has been about being more deliberate there too. Cache what can safely be reused. Rebuild only when the visible state is actually stale. Coalesce reloads instead of treating every small change like a reason to refresh everything immediately.
I care a lot about this kind of restraint. Especially in a product that is meant to support people on low-capacity days, it does not make much sense to build software that is noisy under the hood just to look active on the surface.
That is probably the best summary of the last few days.
Not making the product louder. Not making it busier. Making it ask less from the system, and hopefully a little less from the person using it too.
Some of the most useful development work does not add a new headline feature. It makes the whole thing hold together with less friction.
For now, that feels like time well spent.