I watch before I build.
Most software gets built from descriptions. Someone explains what they need, a developer translates that into screens and buttons, and the result fits the description more than the work itself. The description is rarely wrong, but it is almost never complete.
I learned the alternative in graduate school. I studied anthropology at Edinburgh, where the work involves spending long stretches of time watching people do things they find unremarkable: the routines that have become invisible precisely because they happen every day. The practical lesson is simple: what people say about their work is usually a tidied-up version of what they actually do. The interesting material is in the difference.
My family has run a flower shop in Šibenik for decades. I ran a short-term rental operation for several years. Both taught me that in a small business, friction is rarely where people think it is, and the people closest to the work are usually too busy doing it to describe it cleanly.
Month-Track, BloomOps, and Kibitz all came from that starting point: watching someone's specific Tuesday, finding the one thing that costs them the most, and building only that. Available for projects where the brief says "I wish there was a thing that…"
The method, annotated
Observe
One full day at the desk. No suggestions, just notes.
Name the pain
Write it in the client's words, not mine.
Build the smallest thing
Ship in two weeks. Not a demo — the real tool.
Sit with it
Go back. Watch them use it. Cut what isn't touched.
Expand only when asked
Most projects stop at step three. That's the point.
PS — I write up the observation
notes. You keep them.