At Jam, they initially chose GraphQL for their product due to its flexibility and ability to build lightweight and fast front-ends. However, as they scaled, they encountered challenges with maintainability, debugging, and monitoring. Despite the benefits of GraphQL, such as allowing clients to request exactly the data they need without having to set up multiple backend routes, they have found that it presents unique sets of challenges compared to traditional HTTP REST APIs. These challenges include handling errors in a way that is machine-readable but drops the semantic meaning of HTTP status codes, and collecting timing and monitoring metrics for each endpoint, which can be difficult due to the single endpoint used by GraphQL. The tooling for setting up GraphQL can also be overwhelming, requiring the use of multiple third-party packages and maintaining a schema file and generating client SDKs. Additionally, they have found that the flexibility of GraphQL is not always as beneficial as it seems, as it can shift complexity away from the backend and to the frontend. Ultimately, whether GraphQL was the right choice for Jam depends on their specific needs and context.