TicketBus365 talks to a REST API that somebody else runs and changes. Departures, bus layouts and prices all come from it. The app can be as careful as it likes and still meet a field that is suddenly null, a price in a new shape or a trip that is gone between the list and the click.
Three habits make it livable. Every response goes through a parser that turns it into the app's own types in one place, so a surprise in the data is a single failure and not a crash on some screen. Errors are sorted into the few kinds a traveler can act on: no connection, try again, this trip is no longer available. And a fake implementation of the same repository interface serves the screens in tests, with fixtures for the odd cases.
The fake is the habit I would recommend to anyone. It lets a screen be built and checked without the network, it makes the strange bus a one-line fixture, and it means the day the real API is down is not a day the app cannot be worked on. With Riverpod the swap is a single override.