When outsourcing goes bad, part 14 of 16

Should a toilet be listed as an amenity?

Jul 10, 2024

One reason they were excited to hire me for this project was because of the work that I'd been a part of at FutureStay.

Back in 2008 AirBnB invented what is now called "the short term rental market" or STR as we call it in the biz. Later on VRBO jumped into the same market, and then Booking.com, and recently Google has launched Google Vacations. As property owners become increasingly professional in their approach to the STR market, the need for a unified platform was urgent, and that is where Futurestay entered the picture.

Each STR company had a different history and that history shaped the technology they offered. Booking.com had a long history focused on hotels so when they entered the STR Market they had to bring a vocabulary made for hotels and somehow retrofit that for the new world. For Booking.com, it made sense that a "property" might have 200 units, since for them, a "property" was a hotel. By contrast, for AirBnB, a "property" and a "unit" were the same thing, and the only question was how many rooms did it have?

Then there was the issue of amenities, which each of these companies handles differently.

Should a toilet be listed as an amenity, or should it simply be taken for granted? What if the apartment is in a rural area, in a rural country, where toilets are rare? If a toilet should be listed as an amenity in, say for instance, rural Mozambique, then why not list it as an amenity everywhere, just to be consistent? Every company had a different attitude towards this, and a different attitude towards the concept of "consistency." Some companies felt that an "amenity" should only refer to something unusual, which was sensitive to nuance, others felt that the goal should be rigor, and therefore everything should be listed, as when doing a physical audit of a construction site.

At Futurestay, we needed one universal API that could translate between all of the various company-specific APIs. While I was there we worked towards a better API that might handle the translations with fewer glitches than before. And yet, what the team had done at Futurestay was just child's play compared to what Emory had done. Because integrating the APIs of AirBnB, VRBO, Booking.com and Google Travel is laughably simple compared to integrating the different systems of risk assessment used by the thousands of companies that are part of the commercial insurance industry.

Consumer insurance is fairly simple: if you need car insurance, just go to the GEICO or Progressive or Liberty website, type in some info, pull out your credit card, pay, and presto, you've got insurance!

Commercial insurance is in a different league. If you are the CEO of WalMart, and you'd like to ensure the $20 billion of physical products that you have in your warehouses, you cannot simply go to the GEICO website, pull out your American Express card, and pay for it.

Complex assessments, containing thousands of questions, are standard for commercial insurance. Whereas Kayak and Expedia made it easy to search for travel deals, Luganesk had initially aimed to build a search tool for commercial insurance, but the task was made difficult by the fact that each insurance company uses a different vocabulary for risk assessment. For travel sites, everything is easy because Delta and United and Southwest and Virgin all agree what a “flight” is and they agree what “New York City” is and they agree what “Berlin” is. But in commercial insurance, there was no agreement among companies about what questions to ask, or what the questions mean.

For instance, suppose you own a bakery, and you would like to ensure it. One company asks if your staff has training to fight a fire. Another company asks only, in a general way, if your staff has been trained to deal with emergencies. Another company makes a distinction between medical emergencies (does your staff know how to give CPR) and “industrial” emergencies. And so on, every insurance company defines the task differently, asks differently, and gives different weights to the answers. And because most of these contracts were, until very recently, negotiated in person, many of the insurance companies had no API, so the team at Luganesk had to, in essence, build the API for that insurance company.

All of which meant that, to build such software, one first had to become an expert in commercial insurance. But more so, the different options lead to a combinatorial explosion of possible mappings, when translating from one to the other. If you have a thousand companies that ask a thousand questions about a bakery then you potentially need to map one million options from one to another. And that is just for bakeries. When it comes to commercial shipping, or trucking, or cyber security, or property damage, then you’ve another million, and then another million, and then another million. Emory’s greatest achievement was coming up with a specialized domain specific language (DSL), plus a compiler for that language, that could build a custom system for each industry, merely be scanning in the total set of questions being asked by all companies. Indeed, there may be no other approach that works to get a handle on the overall complexity of the problem.

It may take Arwin some years of effort before he realizes this.

Read the whole series:

1. But what do these glib little bullet points mean?

2. When the CTO does not trust their own team

3. Everyone is under pressure, everyone is too busy to help

4. They lie. They lie flagrantly. They lie all of the time, about everything.

5. That place is a total sweatshop!

6. The Old Team Returns

7. I am very, very proud of you. The work you are doing is amazing.

8. I blame you. You suck. You are the problem.

9. We just got $10,000 dollars!!!!

10. The Taj Mahal was built with blood