As Grounded grew, I started finding problems that were easy to miss when I looked at one screen at a time. The heart monitor could be difficult to connect, flight search worked for some journeys and failed for others, and the character could appear differently depending on the screen. I have used these examples to reconstruct how I would narrow each problem down and check a fix. The symptoms are from the build. Some of the debugging steps below are how I would investigate them again.

When the heart monitor would not connect

I had already used my Fitbit to try the support prompt. When the monitor would not connect, I would start by checking whether Grounded could see the device and receive a reading. I would follow the setup from the beginning, then disconnect and reconnect to see whether the issue appeared on first setup or on a later attempt. Once a reading arrived, I could check the threshold and the prompt separately. That distinction mattered because a missing prompt can look like a connection failure when the reading is already coming through.

My earlier debugging had shown me that connection and resting-heart-rate setup both needed explaining, so I added guidance in the app. To check that change, I would start again with the wearable disconnected and follow only the instructions I had given the traveller. I would also try continuing without the monitor so that a problem with an optional feature could be tested separately from the journey itself.

When flight search worked for UK flights only

A search can look finished if I keep trying it with the flights I used while building it. The UK-only issue showed up when I tried to look beyond those journeys. I would reproduce it with a known UK flight and a known flight departing outside the UK, using the same input format. Then I would check what Grounded sent to the flight service and what came back. If the service returned the international result, I would look for assumptions in the app about which airports or flights to display. If the service returned nothing, I would check whether the request or the data source limited the result.

The fix I would aim for is a search that uses the flight details the traveller entered and handles an empty result clearly. I would retest flights with different origins before treating one successful lookup as evidence that the search worked for the journeys I wanted to support.

When the search would not go into 2027

The year issue was a useful reminder to test dates at the edge of a range. I would compare a late December 2026 flight with an early January 2027 flight and check the date in three places: what I chose on screen, what the app sent, and what the flight service returned. That would show whether I needed to change the date selection, the date sent in the request or how I handled the result. I would also check whether the service supplied a schedule or a live update, since finding a future schedule still leaves questions about which details have been confirmed.

My Family View capture shows a route dated 9 January 2027 and labelled ‘Scheduled · no live update’. That shows a 2027 schedule can appear in that view. I would still repeat the search across the year boundary and compare the details shown in the app with the details in Family View.

The check that helped me most was changing one thing at a time. A second country, a date in the next year or a different route through the app could reveal something I missed in my usual test.

When the character disappeared or stayed visible

I had two separate problems with the character. Sometimes it disappeared when I expected to see it. At other times I had turned it off in Settings and it still appeared on some screens. I would start with the character on and follow the same route through the app, noting which screen lost it and whether it returned when I went back. Then I would turn it off and repeat that route, including screens reached through an alert or an exercise. That would tell me whether the problem followed a particular screen or the way I got there.

For the toggle, I would check that each screen reads the same preference from Settings. If one screen displays its illustration independently, it can keep showing the character after everything else has changed. I would make those screens use the same setting and check both directions, off and back on, including after closing and reopening the app. I would also look at the space left when the character is hidden so the screen still feels complete and the important instruction stays where someone expects to find it.

What this changed about how I test

I want to keep a short list of journeys I can repeat after each change. For Grounded that means trying a wearable with and without a connection, searching for flights in different countries and years, and moving through the app with the character both on and off. Those checks give me a way to see whether a fix still works when I reach the same feature from somewhere else.