A few weeks ago, I wrote about building River, my first “home-cooked meal” app. Turns out, once you build one, it’s easier to build another.

I use Tiller Money to track finances—it dumps bank transactions into a Google Sheet. It’s great! And I’m a huge fan of Google Sheets. On a larger screen, that is. For a smaller screen, a purpose-built interface is always going to do better.

So I built tillerBuddy1.

tillerBuddy is a simple iOS app that lets me edit categories and tags on my Tiller Google Sheet. That’s it. Tap a transaction, pick a category, save. It updates the Google Sheet immediately.

My goal of a better interface has limits though. Most important is the elephant in the room: the Google Sheet must never get corrupted. That sheet has years of financial history, yet I’m vibe coding an interface on top of it! Well, the app makes some concessions. I’m not risking corruption just for smooth UX. So, I forego any modern sync-like behavior. Out the window. And in doing so, I avoid tons of nasty edge cases. This creates some janky UX. In a commercial app, the jank would be unacceptable. But for an audience of one? I’m fine with it. The sheet is reliably updated with minimal corruption risk. And I didn’t have to spend months vetting a complex sync strategy.

That’s the freedom of home-cooked meal apps. Different priorities. I’m optimizing for my specific blend of data safety and usability/polish. It works. It solves my problem.

Two home-cooked apps down.

  1. I have a long history of making “*buddy” apps. At Apple I made a BRB Buddy to help run bug reviews more quickly. I also made a Radar Buddy to help bridge bug tracking data with OmniPlan. At Barnes & Noble I wrote Access Code Buddy to request, you guessed it, Access Codes for books. You get the picture: whenever I make a tool to help out, it usually has the “buddy” moniker. ↩︎