Errandizer
Dump everything you need to run, grab, and get done. Errandizer clusters the chaos into stops and figures out when and how to run them.
Errandizer takes an unstructured list of everything on your plate and turns it into a routed errand run. You type the mess, an LLM clusters it into stops by place, you correct and arrange it by hand, and it works out when to go against your real calendar. The verb model is the spine: a trip is the document, and planning and scheduling are things you do to an open trip.
First time building a native iOS app end to end, and most of the learning lived in the small stuff. The native interaction patterns carry real weight, and once I stopped fighting them the app got better fast. Gestures did more work than taps ever could: drag to arrange the run, drop one stop onto another to merge, swipe to retire a trip. The content wanted to be handled, not clicked. The other lesson was about the model. I ran this on high-effort Opus 4.8, and I think Sonnet would have gotten me to a better outcome faster. It's quicker, less verbose, and it stays in its lane. Opus kept slipping assumptions and recommendations into the plan-to-code loop, and the whole point of how I work is that I make the shaping calls, not the agent. Speed and restraint beat horsepower here.
Three things on deck. All of them need the same prerequisite: more context about the run before it starts.
The plan has no idea how long the whole run will take — just the order.
A route estimator that gives you a time budget before you leave, not a surprise when you're halfway through.
The fastest route and the most fuel-efficient route are rarely the same, and the app doesn't know which one matters today.
Route comparison requires a starting point and preferred store inputs — both on deck, neither shipped yet.
The model doesn't know your go-to grocery store or which Target you actually drive to.
Preferred store matching would let the app cluster to real places you use, not just category guesses.