The NYT on where AI-developed tools are getting traction:
“The future may not be a few huge apps running on a few huge platforms, generating tons of revenue; it could instead be tons of little ones, purpose-built for the church, mutual aid group, company department or softball league. I’d enjoy a future in which the answer to ‘Where’s the great software A.I. was supposed to bring us?’ is: ‘Everywhere.’”
I mean, I work for a software company and given some of the more wild-eyed things people in this industry say, I wasn’t wrong to wonder when we were all going to be given funeral shrouds to pull around us as the vibecoders ushered us to the grave. And I also wasn’t surprised when the CEO said, “look, nobody’s gonna go out with Gemini and make something that works as well as what we make.”
The future does look more like lots of small tools that fill little niches. Or interfaces to coding agents that just drive existing tools. I’ve had a huge amount of success at work, for instance, using Claude to drive GAM when I need to do some toilsome thing in our Google Workspace instance. I’ve written a GAM skill that keeps Claude from actually operating: It has to show me the invocation so I can review it before pulling the trigger for myself. It has taken some analysis that was going to be incredibly tedious and manual and reduced it to 15 minutes of prompts and scripts it writes for itself to analyze the output.
And I’m happy to have that toil gone. I’ve got a small IT team, and when we’ve had to choose between “loads of documentation and a great experience” or “good enough to move on to the next project,” we just focus on keeping the wheels on the bus.
With the analysis work I was doing with our Google Workspace, I’ve had time to make surveys to dial next steps in, think about a comms plan, and do more thorough communications, because I haven’t had to put on my BSA hat and spend a week just doing the analysis. That went down really quickly. I can focus on the things that will feel good to my internal customers.
But this article did make me pause and wonder about the tools I started building with a more “finally, my own Todoist only it’s good” mindset, and how they’ve ended up.
I made a few tools before I got Claude Code that I don’t remember very well. After Claude Code I went on more of a tear.
- A todo app
- A contacts app
- A notes app
- An RSS triage tool
- A bookmarks management tool
- A meta-tool that was my first swing at what a human in the loop could look like after OpenClaw took off.
- A POSSE tool
… and a few revivals of earlier stuff I wrote for myself that I could suddenly evolve much more quickly.
The tasks tool
This one went through a bunch of evolutions: A TUI, a web app, and now an MCP that serves CardDAV. Chasing the UI for a task app wasn’t any fun, and with this setup, I get something helpful: Tasks served in a way that any CalDAV-aware app can handle (Apple Reminders for instance) but with an MCP that agents can talk to, so I can get help getting organized by an agent that also sees my calendar and help me figure out when to plan my tasks.
Any task service with an API would be amenable to something like this, but MCPs that can interact reliably with Apple’s basic productivity services need an always-on Mac. This way I can keep using Reminders, but get at them with Claude from anywhere.
So … still in heavy use. There are alternatives. In the end, the most meaningful design decision wasn’t what a task row looked like, but how the data underneath is organized.
The contacts tool
I made this from an idea I’ve had for a few years that I could sue support managing connections with people. Similar to the tasks tool, I went through a few iterations before settling on a contacts MCP that has a CardDAV back end. So I can manage my contacts with Apple’s Contacts app, but the MCP is there to, among other things, talk to the tasks MCP: When I delegate a task, the contacts app is how the task tool knows who that is. When my calendar has a person the contacts MCP is aware of in a meeting, the MCP logs the interaction.
Again … I started with a custom UI I ended up discaring. Contacts.app is fine. What mattered was the underlying associations.
The notes app
This also did the TUI to web app to MCP pipeline. Now it’s just a daemon sitting on my Mac mini that looks at my notes, periodically reindexes them, makes sure they’re tracked in git, and serves as Claude’s extended memory. I use Obsidian to actually write the notes, but could use anything. I have a Drafts shortcut, for instance, to shoot quick facts into the corpus.
I went back and forth on the data for this and decided, in the end, I wanted nothing in a database even if it would have made some of the agent-oriented stuff simpler.
The tasks, notes, and contacts apps are less “productivity apps” than they are generic data stores I’ve built MCP wrappers around, but left open to use with normal tools. I’m way more interested in how to make my information amenable to use with AI than I am trying to recreate the polished interfaces I can get somewhere else.
The RSS triage tool
I like Feedly as a service a lot, but I didn’t like paying for it and didn’t like that its more advanced features cost even more or required a business plan. I also wanted a learning triage tool to help me get the best out of feeds, preemptively hide things I wouldn’t care about, and slowly build out a prediction model for what I would like.
Similar to my other tools, I wanted to use the existing high-quality RSS apps you can get in the Apple ecosystem, like Unread or NetNewsWire, so I had Claude implement the Fever and FreshRSS APIs to provide the actual RSS service. The MCP underneath is for keeping track of read/unread or feedback from the mobile triage tool I made that makes it easy to periodically tune the scoring engine from my phone.
It’s basically “self-hosted Feedly with my own rules engine and a more proactive scoring system,” and it saves articles I star or like in a client to my Linkding instance after feeding them to a cheap Haiku call that extracts the content of post and taxonomizes it to drive the scoring engine.
Bookmarks
The bookmarks MCP is mostly just a way for Claude to look things up I’ve saved or to process RSS posts I star. Just runs in the background and mirrors my Linkding instance, which provides the front-end for me.
I originally thought about making my own actual bookmarks app, but Linkding is way ahead in UI polish and portability. So the MCP is just a wrapper around it.
The meta tool
This one is truly parked right now. After OpenClaw took off and everyone went a little agent crazy, I had a thought about how I wanted AI to work in my life.
I decided I didn’t ever want an agent to make decisions about certain things. The whole “AI EA” thing was repellent to me because the people trying to make a Jarvis like that plainly didn’t understand the very social nature of assistants. AI calendar apps have existed for a while, and they all suck whether their foundation is more traditional machine learning or newer-fangled inference.
So taking advantage of my control of my tasks, contacts, and notes tools, I made a UI that gave me a quick triage tool for agent-proposed actions:
It learned from what I agreed to and didn’t, and it never allowed an agent to Just Do Something: The action cards were very clear on the change they would make, and the tools that would execute the changes were never, themselves, an LLM: They were strictly deterministic code.
So, for instance, the system would watch my calendar and assess whether a day was too busy and didn’t leave me time to work, but it would just propose moving meetings via the action queue, never do that for me.
Likewise, it would watch my tasks and call out stale ones, or ones that were allegedly “high priority” that kept slipping, but it would never cancel a task or deprioritize it: It would just propose a change I could swipe to approve, or ask why I declined a change so it could learn.
This one is the most novel idea I’ve had. I’ve seen similar implementations but either hated the UI or felt too much inference was being let into the loop. But it’s also the one idea I couldn’t farm out to a better interface. I took a stab at a decision queue operating through Reminders, but the whole thing really wanted its own particular UI and I ran out of patience with it.
My POSSE tool
And finally, there’s my POSSE tool, which is what I use to post pictures, make social posts, and write blog posts.
It has a custom web UI, it uses the AT Proto to store all the content, and it dispatches pictures, blog posts and social posts to Mastodon, my Hugo blog, Pixelfed, and SmugMug. It understands when a shortish post is going long and proposes a summary field so it can seamlessly convert the thing into a blog. It knows I want my Pixelfed picture posts to be boosted by my Mastodon account and shared in a feed page on Hugo.
It basically does what people use IFTTT, Zapier, Buffer, or EchoFeed to do, more or less, but it’s more aware of the content and fits my conception of how a UI should work for this. micro.blog will do this for you for $5/month if you’re good with how they think about POSSE.
So …
All of these tools had long and winding development paths. I started out thinking I was going to Make my Own Things or Do Better than Drafts, but I realized I didn’t like the interfaces I was building that much, and that further what I really wanted – for the productivity-oriented ones – was a data layer AI could work with, but under tighter human-in-the-loop conditions. I use all of them collectively many times a day, and the bulk of them are aware of each other and have APIs for each other, so they use each other many times a day.
I don’t make them public because I don’t write the code and I’m not willing to stand behind them or manage PRs for them. That would be irresponsible.
Which is pretty much like what we’ve all been doing with commodity scripting languages for years: Making things that just go in a directory and get used to solve problems particular to us, in the way we prefer to think about the problem.