So, with some ground rules in place I started by mapping a simple flow for the screens I would need to build something usable. Thanks to a phone being able to record far more contextual information than my fingers, I listed the kinds of data I wanted to capture in each session. Multiple attempts, surface type, location, weather, time, and so on all became available to work with. The original paper chart had been great at visualising progress and boosting motivation, so making meaningful use of this data was important.

In previous experiments I had been enamoured with a Cursor-to-Swift workflow, but in this case it was not going to work with my constraints, particularly the cost and friction of keeping an iOS app running without repeated installs. So, in the spirit of trying something new, I chose to build a web app using Firebase for data and Netlify for hosting.

A short list of features turned into rough sketches. They were just enough to help me think about how to brief Cursor and explore what kind of build might work, however, the first few rounds of generated screens were rough.

I am still learning how to prompt effectively, and I often found myself going in circles with Cursor. We would push one approach for too long when a simpler solution probably existed. After some back and forth, and after deliberately ignoring some of the visual decisions Cursor was making, I arrived at a working prototype I could take outside and test.

Unsurprisingly, but unfortunately, it did not really work. Data was not always recorded. Rapid taps to log kicks triggered zoom gestures. The problems became obvious as soon as it left my desk. Still, I felt that it could improve. I adjusted how I prompted, narrowed the scope, isolated specific problems, and became explicit about what I did not want changed.