To provide some context, we were working on several features that allowed users to perform specific actions based on data we obtained from an external vendor through their REST API.

The product team initially instructed us to use endpoint A to collect user data and to use the results to classify users. However, a few weeks later, they asked us to use endpoint B for user classification, with a fallback to endpoint A if B was unavailable. Additionally, they asked us to consider some data from our database when performing that check.

As nobody was considering the entire situation as a whole, the code was written with conditions spread out throughout the program to check for the availability of different data points depending on the scenario. If a feature needed specific information, the code would search for that only. This resulted in many repeated, decentralized logic statements, leading to poor code quality and maintainability.

Sometime after that, the product team requested another endpoint integration. I remember asking them, "Can we first determine which status a user is in and then use that to drive the UI?" That question triggered a complete re-architecture of this integration.

We started by gathering and aggregating all the necessary information to represent a user's status. This shift allowed us to present a personalized experience across the site, making documentation way easier and ultimately making us talk in the same language (ubiquitous language).

Now, we have a clear-cut system in place. When a user is in "X" status, we know precisely how to proceed. If they are in "Y" status, we do something else. This simple change has significantly impacted our ability to deliver a seamless user experience, track user activity, and many more key aspects of the platform.