On first impression, creating a Hotel App sounds pretty straightforward. But there are more potholes on that road than you can imagine.

Here are the top three challenges you are likely to run into when creating your world class hotel app.

Let’s suppose you are building the next world-class app to look for and book hotels.

One the first things you’ll need to decide is where to get your inventory from. To give your users more choices, you are likely going to get your data from one than one provider. These are called Computer Reservations System (CRS) and there are plenty you can use, like Expedia, Priceline and others.

Having done this, then you’ll start to run into some interesting problems.

Duplicate Results

This problem will become apparent right away.

Oftentimes, different CRS will share some of their inventory. For a given request, they may respond with overlapping hotel result lists. If you are not careful, you might end up showing a list of a hundred hotels to the user when in fact there is just a dozen!

Identifying duplicate hotels can be a troublesome task. There’s no automatic way of matching them reliably.

Identifying duplicate hotels can be a troublesome task. There’s no automatic way of matching them reliably.

Comparing names does not always works. The same can happen with things like addresses. The spelling may be different. Words might abbreviated in one and spelled out in another.

There is no such thing as a universal identifier. Without this, it’s really difficult to tell when multiple listings point to the same property.

Show and Tell … What?

Even after you distinguish common hotels, you will need to decide what to do with the final list. Depending on your business, you could,

  • Show all available prices to the user so, for example, they can pick the cheapest fare available
  • Negotiate with your suppliers and only show hotels from whoever gives you a better cut

Prices Change All the Time

A downside of working with CRS is that you have no control over the actual daily prices. These can change at any time without notice. This means it will be hard for you to keep a price cache to speed up your results. This is due to the sparsity of the searches and the possible combination of dates and locations.

In cases like these, you won’t really have much of a choice.

Keeping Track of Hotel Details

Your users will need more than pricing in order to book anything.

How does the hotel look like? Does it have free Wi-Fi? What about a gym? What other amenities each offers.

Hotel details may be provided by some CRS along with the price, but not all of them work that way. Sometimes an extra API call is needed, but not all of them will return the same level of detail. In these cases, having multiple alternative sources can help you get enough juicy details to get your users to click that “book” button.

As opposed to pricing, this data doesn’t change everyday. So, it’s a good idea to keep some kind of cache to prevent slowing down your search response times. The amount of details could grow quickly, so do keep an eye on your available memory.


As you can see, many of the issues above get more complex as you add more hotel providers.

If you have a service-oriented architecture, many of these problems could be easier to solve. This kind of architecture allows you to allocate resources to individual, more demanding tasks that impact your response times.

Creating the right abstractions is very important. But just as important is having a great team of engineers to help you write beautiful, well-tested code to make your travel app solve all of these challenges and more.