Startup Story: EataCity From Start to Finish

I created EataCity because travel is important me. I want more people to travel, to explore, and to have genuine connections with the world around them. Eating is a great way to connect with a foreign land and its people. We all eat, and food has the ability to pull people together, to create shared experiences and a greater appreciation for other cultures. To eat in a foreign country is to experience that country.

The Problem to Solve

I felt (and still feel) that it’s too hard to find genuine places to eat when travelling to a new city. There are some user-generated travel websites that provide guidance from other travellers on where to eat. But frankly, they suck. Homer from Springfield doesn’t actually know much about ramen in Tokyo, in fact he doesn’t really know much about Japanese food in general. Traveller review sites are great for things like hotels and sightseeing, but when it comes to food, they end up creating little echo chambers in which everyone ends up in the same places. So when I say genuine, I mean food that is unique to that city, has a place in that city, or is just so damn good it deserves a mention. Recommendations for these types of places already exist on the internet. There isn’t a lack of good content, on the contrary, there are a tonne of great travel writers, professional restaurant reviewers and food bloggers. But all of this content sits in little silos. With EataCity I didn’t want to write another travel guide, I wanted to tap into existing content and make it more discoverable. So how was I going to do it?

The Idea

I would find the best food writers and local food bloggers with relevant content for foodie travellers. Then use web crawling and machine learning to auto-tag reviews and curate them into city guides with links back to the original websites. This would make it easier for travellers to find the best places to eat as chosen by those who know the city well.  At the same time, I’d be generating traffic for and promoting local food bloggers. Win for the traveller, win for small food blogs.

The Business Model

Now, how was I going to make money out of this? I knew it would be a tough job generating ad revenues given that I wasn’t going to have a lot of original content which means low SEO, and I was targeting a segment with a relatively infrequent need. For both of these reasons, I knew it would be hard to drive a regular audience and readership, which meant getting enough page views for an ad-based revenue model would be hard. I could create an app and charge for it, but a core piece of the proposition was linking back to the original blogger’s website and I couldn’t offer a roaming friendly offline version while providing those backlinks (for obvious copyright reasons I wasn’t going to copy the whole review and post it on EataCity). 

Product Design

So I opted to curate the recommendations around neighbourhood guides that included hand-picked hotels with affiliate links to a booking platform to generate revenue. To do this I was targeting people in the discovery stage of booking travel, maybe they had already booked flights, but wanted to know where to eat and in which neighbourhood they should stay in. Typically this exploratory stage (especially for my target segment of full-on foodies) is done on a laptop/desktop. So EataCity would look like this:

  • A desktop-centric (but mobile responsive) Django web app.

  • Crawl and auto-tag restaurant review websites using machine learning techniques.

  • Curate all reviews into a city guide displaying tags, review title, and link back to the original creator.

  • Auto update content using RSS as new reviews are posted.

  • Segment the city into neighbourhoods with affiliate links to hotels ($$$).

  • Easy, right? What could possibly go wrong?

Building It

Ok, so the first step was to learn how to build a web app. I had some experience with SQL and JavaScript in past roles, but building a website was new territory. I won’t go into great detail here as I’ve covered how I built the site and the tools I used in this post. First step was to find local content to include in each city guide. This was actually pretty straight forward. Find bloggers, crawl their site, grab the post title, link back to the original post, and then add each restaurant reviewed onto a Google Map.

Google have some great APIs for this type of thing. The hard part was knowing that the place called ‘Taberna Laredo’ on Google Maps was the same place bloggers were referring to in the reviews titled: “Tapas at Laredo”, “Restaurant Laredo” or “Dining at Madrid’s Laredo”, but not the same as “Finding a Taberna in Madrid”. As an aside, I had hoped that the web would generally head toward a Structured Data approach and this would make place matching between content and Google Maps easy. Alas, this hasn’t happened and very few, if any, bloggers use structured data.

In the early days, I had a fairly manual approach to matching these up. I used the Google Maps API and a text matching Python package to give me a match score. If a review title matched a Google name perfectly then it would get auto added to my database, whereas if there was a low level of similarity between the title and a Google place name it would throw up an exception. I got better at this once I started matching URLs mentioned in reviews with the website address in the Google Maps Place Details API. URLs have a higher level of uniqueness and I had a far higher success rate than using just the review title.

So now I had a bunch of popular restaurants in a city with links to food blogger reviews of the restaurants. Quickly a couple of problems emerged: depth and quality of content. A few of the early cities, for example Madrid, Prague, Munich, Vienna and Barcelona, are all great food and travel destinations, but the proposition just didn’t stack up. Firstly, there weren’t enough bloggers in each city to warrant a curated guide. And secondly, for cities where there are lots of bloggers, e.g. London, Paris and Singapore, I didn’t have a great library of images to pull from and the images I could use were poor. In an Instagrammable world, this is a problem. People want photos!

From tech-founder to… food blogger?

The solution to this problem became mistake number one. I hit the road… I packed up my camera and started eating! There’s good reason for doing this; I had to be user number one and prove that the guides actually worked. And then there’s a bad reason for doing this; I thought I needed some of my own content like photos and reviews to beef up the general appearance and quality of the website. But I temporarily forgot that I wasn’t trying to be a food blogger, I was supposed to be creating a data driven approach to food travel guides. The upside was that I got to do a bunch of travelling and eating at some amazing restaurants.

Over the course of 18 months, I visited over 600 restaurants, cafes and street food stalls from Tokyo to London. Not to mention, plenty of great bars in between. And because I was creating neighbourhood guides that included hotel recommendations to support the revenue model, I made a point of never staying in the same hotel for more than 2 nights. If I was in a city for 4 days, that would mean staying in at least 3 hotels in 3 different neighbourhoods. It was a great experience! (Except the time we were caught up in the Paris terrorist attack.)

The quality of the content on the site got better, my photography skills got better, and I learned the difference between a bad hotel and a great hotel. But the only thing scaling up was my waistline. It turns out that eating at 5 restaurants a day isn’t that great for your health. On top of that the cost of all this travel was starting to add up. Not that my co-investor (my wife) seemed to mind, she’s an even bigger foodie than me and was happy to come along on several trips to help empty the plates and glasses.

So then the revenue started to roll in?

Now this would have been fine if my assumptions about the revenue model stacked up, but they didn’t. My original assumptions around traffic and conversion required to generate the first $100k in revenue seemed embarrassingly small. Boy was I wrong! The revenue I was getting from hotel bookings through my affiliate partner didn’t come close to covering costs. I don’t blame the booking platform, I blame my naivety.

Firstly, getting traffic was harder than I thought. I was competing on SEO with some big established players, and in SEM, I was competing with a bunch of other established players willing to spend big $$$ on CPC. I could get traffic to the site, I could send this traffic to the hotel booking platform, but it wasn’t converting into bookings at rates that were anywhere close to what I was expecting. The SEO pros will tell you that original content is the way to boost your ranking, so I was stuck between a rock and hard place. I wanted to build a scalable website that curated existing content without the need to constantly write my own content. It’s this conflict that ultimately led me to walking away. Google promotes original content creators over curators and aggregators like EataCity and for good reason. I knew this going in, but a little hubris got in the way. I assumed my amazing product would overcome this hurdle.

Build, Break, Learn, Fix and Repeat.

Over the last 6 months, I tried a few things to scale the site. For example, I created a sentiment analysis program to find the restaurants most liked by bloggers. Unfortunately, this didn’t work, some bloggers give very dry objective descriptive reviews like “I ate a tapas of shrimp on toast”. Basically no sentiment at all. And others write very long reviews that meander in all sorts of directions, something like: “when I visited restaurant X I had fond memories of my time in Spain, the wonderful food, the tapas, fresh seafood and delicious wines. Last month I went to another Spanish restaurant in London called restaurant Y, and it was exactly how I remember Spain, it was utter perfection. Unfortunately, restuarant X does doesn’t stack up. The food missed the mark, it was bland and horrible.” Trying to get a sentiment analyser script to understand what’s going on there is simply beyond my programming skills. So I shelved that one.

I also played around with machine learning and clustering. It worked a little like an Amazon recommender engine to group similar reviews together. Alas, this didn’t work as well as manual curation. In some cities the best restaurants might be a mix of fine dining, local neighbourhood restaurants, and a random Thai place (yes, I’m talking about you Copenhagen). Clustering with machine learning does the complete opposite of this. My last ditch attempt at keeping it alive was to create a purely code-driven guide and see if it worked as well as the current guides. I would rely only on code with little/no manual interference from me. Enter Mexico City. For this I used TFIDF, or Term Frequency Inverse Document Frequency.

So a quick intro to TFIDF. Step one, take all of the reviews in a city and dump all the words in those reviews into a big bag. Now take all of the reviews about a certain restaurant and dump them into a smaller bag. Now compare the words in the restaurant bag against the words in the city bag. TFIDF gives each word/phrase a score based on how frequently it is used to describe a restaurant versus how often that word/phrase is used to describe all restaurants. So a word like ‘good restaurant’ that is used very often gets a very low score, but infrequent phrases like “fresh seafood” and “tuna tacos” get high scores. This way you can tag restaurants against key words/phrases.

So I set up scripts to:

  • Crawl all reviews of restaurants in Mexico City, with links back to original post.

  • Match review URLs to Google Place Details web URLs.

  • Crawl the whole review and create a bag of words model for TFIDF.

  • Use TFIDF to generate tags to describe restaurants, e.g. Reviewers of Don Toribio talk about: "Argentinian/Mexican Parrilla", "Huevos Rancheros", "Milky Coffee", "Old-World Atmosphere Bills", "Skirt Steak", "Spacious 19Th-Century Salon", "Spicy Tomato Sauce", "Sweet Rolls", "Tortilla Soup" and "Typical Mexican Breakfasts".

The result was something that users thought showed promise but needed work. I thought with some tweaking, I’d be able to get it to a place that worked pretty well. But… the guide still lacked what people wanted: photos. I thought about continuing with a word-based website with just a few images, perhaps one per restaurant. But in the end I couldn’t solve the revenue problem. I could scale up EataCity with this approach, but the UX was suboptimal and I still had no way of making enough money to justify the time spent building it.

An Empty Plate

And so that is the finish of EataCity. I’m going to keep it alive to play with on the side, but it’s no longer a full-time deal. Hopefully, this will be useful for anyone wanting to do something similar in the future. If you want more detail or to chat about what I did, feel free to contact me.

Happy travels!