A Sunday of MVP planning, Broddy foundations, and a pi.dev essay
Moved a client MVP from docs into a clearer execution path, landed the first Broddy assistant commit, researched self-hosting options, and drafted a pi.dev blog post.
Sunday had more structure than I expected. It started as scattered research and ended with one mobile assistant commit, one content draft, and a clearer path for a client MVP.
Client project (NDA)
The client project moved from product modeling into execution planning. I consolidated the remodeled MVP docs, aligned guides, and closed the routing decisions that were still too loose. This is the kind of work that does not look flashy, but it makes parallel implementation possible. When the docs, screens, and routes agree, agents can take separate slices without fighting the same ambiguity.
Broddy
I landed the first real Broddy commit: an on-device personal assistant with chat, voice, reminders, and calendar direction. It is still early, but the shape is there. The main technical question is how much intelligence can live close to the device without wasting the user's paid usage or assuming a server is always nearby.
I also looked at React Native AI patterns and edge inference references. The conclusion was practical: the mobile app should stay a client, and any heavier Pi runtime should live in a sidecar, local service, private server, or sandbox with a typed bridge. React Native should not pretend it has the same runtime as Node.js.
tgmarinho-ai-website
I drafted a blog post about pi.dev: what it is, how it is built, why extensions matter, where TypeScript helps, what alternatives exist, and what I recommend building with it in 2026. The strongest idea in the draft is that Pi is not only another agent surface. It is a way to package repeatable workflows as small, local, hackable tools.
iTOP
I also studied whether SST could help the event platform, especially around deployment shape and self-hosting. No architecture changed yet. This was a useful check before reaching for new infrastructure.
Good Sundays do not need to be loud. This one gave Monday enough structure to move faster.