The Unexpected Cost of Using Google Places API

One day, I opened my bank account statement and realized I got charged $100 from Google Console Team. My first reaction was, “What!? I thought it was free”. I immediately contacted our project team, and we had to pause all the development.

So, what were we trying to develop? To quickly re-cap, Labs™ is our special internal space to experiment with ideas and technologies. In other words, a creative playground for our developers and designers. During one of our Labs meetings, one of our team members proposed the idea of developing a custom application to locate the best local taco restaurants in town. Being blown away by the concept, we cooked up a set of features, including a map, markers for taco restaurants, a sidebar for information, plus routing and directions to get to a specific restaurant. From there, the custom Tacolocation app was born. 

We were very excited to customize the experience for our users, from crafting an intuitive design to filtering out local taco restaurants located at users’ locations. Above all, we were dedicated to creating an application that was not just a map but a hub for taco junkies everywhere. 

Our first objective was to research clean and reliable data on taco restaurants. However, it was more challenging than we thought. The data we encountered was either incomplete or raw and static in an excel sheet. Since the data was currently separate, we were concerned with how to fetch data into our codebase. To adapt to the limitation, we decided to venture out to look for an application programming interface (API). An API allows our browser to communicate with a web server to request the needed data.

We found that the Google Places API  would be an excellent solution. With Google Maps as one of its core businesses, Google has collected geographical data from businesses and places all over the world. This data is stored in Google’s servers and can be retrieved anytime using Google APIs. Specifically, the Places API returns data under JSON (JavaScript Object Notation) format, which is written as name/value pairs such as { “firstName”: “John” }. This format is very developer-friendly and easy to work with. With the Places API, not only can we request basic information such as name and address, but we can also retrieve reviews and photos of a restaurant.  We also used the Distance Matrix API to calculate the distance from a user's position to a specific restaurant. The Directions API can also be used to show directions to get to a restaurant by the user’s preferred mode of transportation.

The raw truth of it all was that we did not have a budget to spend on this project, which eventually cost us a great deal of time and consideration. To use Google’s API services, Google Cloud required us to create a billing account, even though we were eligible for the free tier. According to the cloud documentation, a free tier allows us to use certain products at no cost and provides us with $300 in credits as a new customer. Given the impression that using the API  is ‘free’, we were shocked to see the $100 charge by Google Console. We had no idea why there was a charge and where it came from. 

Looking into the report from Google, we realized that there was a huge and unreasonable number of requests (~48,000 ) within only 20 days. Assuming that every refresh or reload is one to several API requests, we did not expect to make that many requests when we had not yet shared the application with the world. By investigating further, we learned that there are many hidden factors that cause the number of requests to skyrocket. For example, we did not understand how many requests were made every time we refreshed the application or clicked on its elements. Secondly, we naively assumed that on the free tier, everything would be free. Unbeknownst to us, there is a threshold of $200, and if the accrued cost is over $200, our account associated with the API will be charged automatically. Thirdly, we found some operational inefficiencies in our code that we needed to avoid, such as loop calls - requests that repeat themselves many times. Unfortunately, no matter how many documents we tried to dig into for a better understanding, we could not find the answers we needed.

Did we stop using Google APIs? After weighing the pros and cons of using the service without a solid understanding of how the requests work, we made the decision to pivot in a different direction. What we care about the most is bringing value to our users and getting our hands dirty in data visualization. Due to budget constraints, we crafted a JSON file on our own as a fixed set of data for rendering places. As a developer, this is not the most exciting thing I would want to tackle because we all love for things to be automated and dynamic. However, we managed to keep 70% of the features we initially set out for.

Unfortunately, the biggest feature we had to remove was that users can no longer get suggestions based on their specific location. Also, the application could not provide directions from point A to point B anymore. Instead, every time they go to the application, they will see the same set of restaurants in Raleigh, NC where our WeWork office is located. Additionally, to try and counteract this issue of not using the Distance API, we wrote a function to calculate the distance between two locations on a straight line using latitude and longitude. With these development changes, we had to switch our original goal from servicing our users to creating a Minimum Viable Product (MVP) and using this project as a way to demonstrate our custom development capabilities.

Although the outcome was not what we expected initially, we took away valuable lessons for our future Labs projects. First, setting a specific budget and researching potential costs for a project should be the number one priority, just like when we are scoping out client projects. Sometimes we can get too excited about our Labs ideas and want to implement them immediately. However, taking a step back to measure feasibility based on our resources is wise.

Similar to how we work with our clients, we should have had a discovery phase to see if the work we wanted to do aligned with the budget. Another lesson we encountered was the readiness to pivot. With a mindset of being agile, we want to learn faster about what does not work to have more time iterating on what works. We find this incredibly useful when we research and receive feedback from end-users or when we collect insights from our clients. Our designers and developers are willing to work backward and make adjustments if it makes sense. Through this project, we built our muscles on working with APIs and weighing between technology and project management standpoints to make tough decisions.

And we managed to get some tacos in place. Check it out: https://tacolocation.netlify.app/