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.
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.
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.
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.
<aside>
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.
</aside>
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.
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.