mike-puddingtime-org-wurm4a.txt (11841B)
1 [1]hi, it's mike [2]Posts [3]Tags [4]Search [5](Toggle day/night mode)☾ night 2 [6]Home / [7]Posts / It was really just life hacks all along 3 4 It was really just life hacks all along 5 6 September 14, 2026 · 9 min read · 1881 words 7 8 I’ve made a bunch of apps and tools in the past two years and this NYT article 9 encouraged me to ask “where are they now?" 10 11 The NYT on [8]where AI-developed tools are getting traction: 12 13 “The future may not be a few huge apps running on a few huge platforms, 14 generating tons of revenue; it could instead be tons of little ones, 15 purpose-built for the church, mutual aid group, company department or 16 softball league. I’d enjoy a future in which the answer to ‘Where’s the 17 great software A.I. was supposed to bring us?’ is: ‘Everywhere.’” 18 19 I mean, I work for a software company and given some of the more wild-eyed 20 things people in this industry say, I wasn’t wrong to wonder when we were all 21 going to be given funeral shrouds to pull around us as the vibecoders ushered 22 us to the grave. And I also wasn’t surprised when the CEO said, “look, nobody’s 23 gonna go out with Gemini and make something that works as well as what we 24 make.” 25 26 The future does look more like lots of small tools that fill little niches. Or 27 interfaces to coding agents that just drive existing tools. I’ve had a huge 28 amount of success at work, for instance, using Claude to drive GAM when I need 29 to do some toilsome thing in our Google Workspace instance. I’ve written a GAM 30 skill that keeps Claude from actually operating: It has to show me the 31 invocation so I can review it before pulling the trigger for myself. It has 32 taken some analysis that was going to be incredibly tedious and manual and 33 reduced it to 15 minutes of prompts and scripts it writes for itself to analyze 34 the output. 35 36 And I’m happy to have that toil gone. I’ve got a small IT team, and when we’ve 37 had to choose between “loads of documentation and a great experience” or “good 38 enough to move on to the next project,” we just focus on keeping the wheels on 39 the bus. 40 41 With the analysis work I was doing with our Google Workspace, I’ve had time to 42 make surveys to dial next steps in, think about a comms plan, and do more 43 thorough communications, because I haven’t had to put on my BSA hat and spend a 44 week just doing the analysis. That went down really quickly. I can focus on the 45 things that will feel good to my internal customers. 46 47 But this article did make me pause and wonder about the tools I started 48 building with a more “finally, my own Todoist only it’s good” mindset, and how 49 they’ve ended up. 50 51 I made a few tools before I got Claude Code that I don’t remember very well. 52 After Claude Code I went on more of a tear. 53 54 • A todo app 55 • A contacts app 56 • A notes app 57 • An RSS triage tool 58 • A bookmarks management tool 59 • A meta-tool that was my first swing at what a human in the loop could look 60 like after OpenClaw took off. 61 • A [9]POSSE tool 62 63 … and a few revivals of earlier stuff I wrote for myself that I could suddenly 64 evolve much more quickly. 65 66 The tasks tool 67 68 This one went through a bunch of evolutions: A TUI, a web app, and now an MCP 69 that serves CardDAV. Chasing the UI for a task app wasn’t any fun, and with 70 this setup, I get something helpful: Tasks served in a way that any 71 CalDAV-aware app can handle (Apple Reminders for instance) but with an MCP that 72 agents can talk to, so I can get help getting organized by an agent that also 73 sees my calendar and help me figure out when to plan my tasks. 74 75 Any task service with an API would be amenable to something like this, but MCPs 76 that can interact reliably with Apple’s basic productivity services need an 77 always-on Mac. This way I can keep using Reminders, but get at them with Claude 78 from anywhere. 79 80 So … still in heavy use. There are alternatives. In the end, the most 81 meaningful design decision wasn’t what a task row looked like, but how the data 82 underneath is organized. 83 84 The contacts tool 85 86 I made this from an idea I’ve had for a few years that I could sue support 87 managing connections with people. Similar to the tasks tool, I went through a 88 few iterations before settling on a contacts MCP that has a CardDAV back end. 89 So I can manage my contacts with Apple’s Contacts app, but the MCP is there to, 90 among other things, talk to the tasks MCP: When I delegate a task, the contacts 91 app is how the task tool knows who that is. When my calendar has a person the 92 contacts MCP is aware of in a meeting, the MCP logs the interaction. 93 94 Again … I started with a custom UI I ended up discaring. Contacts.app is fine. 95 What mattered was the underlying associations. 96 97 The notes app 98 99 This also did the TUI to web app to MCP pipeline. Now it’s just a daemon 100 sitting on my Mac mini that looks at my notes, periodically reindexes them, 101 makes sure they’re tracked in git, and serves as Claude’s extended memory. I 102 use Obsidian to actually write the notes, but could use anything. I have a 103 Drafts shortcut, for instance, to shoot quick facts into the corpus. 104 105 I went back and forth on the data for this and decided, in the end, I wanted 106 nothing in a database even if it would have made some of the agent-oriented 107 stuff simpler. 108 109 The tasks, notes, and contacts apps are less “productivity apps” than they are 110 generic data stores I’ve built MCP wrappers around, but left open to use with 111 normal tools. I’m way more interested in how to make my information amenable to 112 use with AI than I am trying to recreate the polished interfaces I can get 113 somewhere else. 114 115 The RSS triage tool 116 117 I like Feedly as a service a lot, but I didn’t like paying for it and didn’t 118 like that its more advanced features cost even more or required a business 119 plan. I also wanted a learning triage tool to help me get the best out of 120 feeds, preemptively hide things I wouldn’t care about, and slowly build out a 121 prediction model for what I would like. 122 123 Similar to my other tools, I wanted to use the existing high-quality RSS apps 124 you can get in the Apple ecosystem, like Unread or NetNewsWire, so I had Claude 125 implement the Fever and FreshRSS APIs to provide the actual RSS service. The 126 MCP underneath is for keeping track of read/unread or feedback from the mobile 127 triage tool I made that makes it easy to periodically tune the scoring engine 128 from my phone. 129 130 It’s basically “self-hosted Feedly with my own rules engine and a more 131 proactive scoring system,” and it saves articles I star or like in a client to 132 my Linkding instance after feeding them to a cheap Haiku call that extracts the 133 content of post and taxonomizes it to drive the scoring engine. 134 135 Bookmarks 136 137 The bookmarks MCP is mostly just a way for Claude to look things up I’ve saved 138 or to process RSS posts I star. Just runs in the background and mirrors my 139 Linkding instance, which provides the front-end for me. 140 141 I originally thought about making my own actual bookmarks app, but Linkding is 142 way ahead in UI polish and portability. So the MCP is just a wrapper around it. 143 144 The meta tool 145 146 This one is truly parked right now. After OpenClaw took off and everyone went a 147 little agent crazy, I had a thought about how I wanted AI to work in my life. 148 149 I decided I didn’t ever want an agent to make decisions about certain things. 150 The whole “AI EA” thing was repellent to me because the people trying to make a 151 Jarvis like that plainly didn’t understand the very social nature of 152 assistants. AI calendar apps have existed for a while, and they all suck 153 whether their foundation is more traditional machine learning or newer-fangled 154 inference. 155 156 So taking advantage of my control of my tasks, contacts, and notes tools, I 157 made a UI that gave me a quick triage tool for agent-proposed actions: 158 159 It learned from what I agreed to and didn’t, and it never allowed an agent to 160 Just Do Something: The action cards were very clear on the change they would 161 make, and the tools that would execute the changes were never, themselves, an 162 LLM: They were strictly deterministic code. 163 164 So, for instance, the system would watch my calendar and assess whether a day 165 was too busy and didn’t leave me time to work, but it would just propose moving 166 meetings via the action queue, never do that for me. 167 168 Likewise, it would watch my tasks and call out stale ones, or ones that were 169 allegedly “high priority” that kept slipping, but it would never cancel a task 170 or deprioritize it: It would just propose a change I could swipe to approve, or 171 ask why I declined a change so it could learn. 172 173 This one is the most novel idea I’ve had. I’ve seen similar implementations but 174 either hated the UI or felt too much inference was being let into the loop. But 175 it’s also the one idea I couldn’t farm out to a better interface. I took a stab 176 at a decision queue operating through Reminders, but the whole thing really 177 wanted its own particular UI and I ran out of patience with it. 178 179 My POSSE tool 180 181 And finally, there’s my [10]POSSE tool, which is what I use to post pictures, 182 make social posts, and write blog posts. 183 184 It has a custom web UI, it uses the AT Proto to store all the content, and it 185 dispatches pictures, blog posts and social posts to Mastodon, my Hugo blog, 186 Pixelfed, and SmugMug. It understands when a shortish post is going long and 187 proposes a summary field so it can seamlessly convert the thing into a blog. It 188 knows I want my Pixelfed picture posts to be boosted by my Mastodon account and 189 shared in a feed page on Hugo. 190 191 It basically does what people use IFTTT, Zapier, Buffer, or EchoFeed to do, 192 more or less, but it’s more aware of the content and fits my conception of how 193 a UI should work for this. [11]micro.blog will do this for you for $5/month if 194 you’re good with how they think about POSSE. 195 196 So … 197 198 All of these tools had long and winding development paths. I started out 199 thinking I was going to Make my Own Things or Do Better than Drafts, but I 200 realized I didn’t like the interfaces I was building that much, and that 201 further what I really wanted – for the productivity-oriented ones – was a data 202 layer AI could work with, but under tighter human-in-the-loop conditions. I use 203 all of them collectively many times a day, and the bulk of them are aware of 204 each other and have APIs for each other, so they use each other many times a 205 day. 206 207 I don’t make them public because I don’t write the code and I’m not willing to 208 stand behind them or manage PRs for them. That would be irresponsible. 209 210 Which is pretty much like what we’ve all been doing with commodity scripting 211 languages for years: Making things that just go in a directory and get used to 212 solve problems particular to us, in the way we prefer to think about the 213 problem. 214 215 Tagged: [12]Ai, [13]Tools, [14]Software, [15]Vibecoding 216 [16]← The new porch 217 [17]mastodon · [18]github · [19]linkedin · [20]pix · [21]email 218 © 2026, mike 219 220 References: 221 222 [1] https://mike.puddingtime.org/ 223 [2] https://mike.puddingtime.org/posts/ 224 [3] https://mike.puddingtime.org/tags/ 225 [4] https://mike.puddingtime.org/search/ 226 [6] https://mike.puddingtime.org/ 227 [7] https://mike.puddingtime.org/posts/ 228 [8] https://www.nytimes.com/2026/09/12/opinion/ai-software-coding-apps.html?unlocked_article_code=1.AlE.C9EE.H2j5a1eHFUbQ&smid=nytcore-ios-share 229 [9] https://indieweb.org/POSSE 230 [10] https://indieweb.org/POSSE 231 [11] https://micro.blog/ 232 [12] https://mike.puddingtime.org/tags/ai/ 233 [13] https://mike.puddingtime.org/tags/tools/ 234 [14] https://mike.puddingtime.org/tags/software/ 235 [15] https://mike.puddingtime.org/tags/vibecoding/ 236 [16] https://mike.puddingtime.org/posts/2026-08-22-the-new-porch/ 237 [17] https://hachyderm.io/@mph 238 [18] https://github.com/pdxmph 239 [19] https://www.linkedin.com/in/michaelhallpdx/ 240 [20] https://pix.puddingtime.org/ 241 [21] mailto:[email protected]