In CS 177 we talk a lot about how systems fail, but breaking real apps makes the tradeoffs feel much more obvious. Looking at Slack, Uber, and banking apps through that lens shows how tightly error handling is tied to each company’s business model.
With Slack, a message that will not send is more than an inconvenience. It shakes the core promise that teams can depend on Slack for day-to-day coordination. If that reliability slips, companies start questioning whether they should renew or switch tools. Slack’s recovery flows reflect that pressure. Messages retry automatically, the app is transparent about what is pending, and it tries to keep you productive even when connectivity is spotty. All of this exists to defend retention, which is Slack’s real engine.
Uber feels completely different. Errors here have an immediate revenue cost. A failed ride request or a bad ETA usually ends with the user closing the app and picking another option. That is a lost fare and lost driver time. Uber’s recovery design is basically an attempt to save the trip before you leave. It retries matches, offers fallback pickup options, and fixes payment issues on the spot. Speed matters because every minute of friction equals money left on the table.
Banking apps sit in their own category. When something fails, users do not think “bug,” they think “is my account wrong.” Even small errors damage trust, which is the foundation for deposits, card usage, and long term loyalty. This is why banks show very explicit error states, queue payments safely, and give multiple ways to authenticate if one path fails.
Testing these failures makes it clearer how error handling is less about UI and more about protecting the parts of the business that cannot break.
