By Pierre-Camille Hamana
CEO and Founder of Hospitable
In the world of software, businesses can only make one fundamental mistake: you never, ever, ever rebuild the product and the code from scratch.
The notorious example is that of Netscape (the grandad of all Internet browsers): Version 4.0 was released in 1997 (I was 11 at the time). Version 6.0 was released in 2000. There never was a version 5.0 in between. And the reason for that is they tried to rebuild the entire thing, and it never materialized. Microsoft also attempted to rewrite Word from scratch in a project called Pyramid: it collapsed, and they shut it down.
Oddly, I find myself today in the position of explaining why we decided to rebuild the product anyway in spite of those horror stories, and how we did it in the past nine months.
I am quite looking forward to revisiting this in the next few months, certain that the promise offered by the new product will be delivered.
Why the former design would no longer work
Building a Saas product is a tale of velocity: ship a minimal product, expose it to users and iterate as quickly as possible based on their feedback.
I developed Hospitable from my bedroom, while my Airbnb guests were enjoying the rest of my home. The development then could be very fast: The customer service team (myself) would report to the engineering team (myself), and “we” were able to deploy in a matter of a few hours. That actually lasted for just about six months.
Then something unexpected happened: growth. What started as side-project that was fun to work with became a full business.
With a growing number of new customers each week, customer service and sales became a full-time activity, and it was harder to iterate. The first two Hospitable recruits, Marii and Matthew, were entirely dedicated to building a fantastic support team.
An engineering team came onboard quick after to support the development, with a mission to build completely new products in their own right. Nikita was able to build our #1 feature request with a new integration to HomeAway, both for Messaging and Sync. Jovana built our Metrics product, which was our first expansion into an area where we were not expected.
We later gathered in Prague in November 2018, after recruiting a designer (Ekrem) and a new frontend developer (Ben) to discuss what was coming next. This was the first time a team with eight people could openly discuss next month’s strategy. We decided then to rebuild Hospitable and redesign it from scratch.
The design was made for our own convenience and was not state of the art for our users.
When I created Hospitable, I was hosting just a private room on Airbnb.
I didn’t realize there would be property management companies out there managing hundreds of thousands of accounts and properties. What made sense to me then, from my own experience, was managing everything at a listing level, or at the account level. This was convenient for many technical and design reasons.
Turns out: short-term rental property management businesses do exist (duh!), and they now represent half of our user base. Our user interface didn’t serve them well enough to allow them to manage entire portfolios conveniently. We had to fix that.
The design was articulated around Airbnb only, and could not support multiple channels.
The HomeAway/Vrbo integration was our #1 feature request. We delivered it only to realize that, because of design limitations, the experience would be “sub-optimal.”
As users were connecting their HomeAway accounts, they realized, to their surprise, that they now had a set of rules for each platform.
Considering an owner with a single property would have at least eight rules, it means they would have 16 rules to maintain and update.
This issue would compound as the easiest way to expand our product, and the most demanded is to integrate with more channels. Our #1 feature request today is Booking.com, so that would mean, for the simplest scenario possible, around 24 rules to maintain.
We needed to fix that while accounting for the fact this would mean a considerable re-engineering of our most critical features.
Our code base was getting impossibly complicated to maintain.
The last nail in the coffin was the fact that, in a word, Hospitable evolved, and the engineering had to evolve as well.
Hospitable was built on top of a micro-framework (Slim) that is perfect for quick iteration for small projects. We acknowledged the fact that we needed to be equipped for building a multi-feature products, and even a multi-products business.
We needed to migrate from this home-brewed codebase to Enterprise-class engineering, consolidate our codebase, and optimize again for velocity.
It is a fantastic opportunity to consolidate two years of feedback at once
After two years in business, we learned a lot, and we asked a lot of questions to our users to have an acute understanding of their problem. The main job of our customer service team is actually to investigate the many feature requests we receive and to question what is the problem this is solving.
I believe this approach is fundamentally what differentiates martbnb. There are many solutions out there that have more features and can address more problems.
But if you want to solve (actually solve) the problem of delivering personal guest communication at scale, only Hospitable is reliable and flexible enough. Our customers are not frustrated about their guest communications provider: They write 5-star reviews that keep us humble for the impact we have on their lives.
In practice, iterating on feedback is great while it lasts, but some things require a full rethinking. We knew this had to happen. The only question is deciding whether we want to accomplish this gradually, or at once.
The choice was to make a radical change, which meant handling all the complexity of this project, as early as possible. I believe it is the least disturbing choice and the one that will enable us to iterate faster.
Rebuilding, sure, but what to build?
I believe the feedback for our customers is in three directions:
Our users want a product that just works.
If the success of Zoom or Slack is any indication, having a product that just works is already passing the bar.
We do know that when there is any hiccup, this does result in the most frustrating guest experience. We have committed, and we still commit, at least half of our engineering hours on having a solution to any bug, however unlikely, may arise.
I find this is the most exciting part of this process: taking the time to consolidate, architect, test, and just offer a predictable and reliable software. We can showcase great numbers in that regard, with 100,000 messages sent each week, and a 99.9% success rate.
For the product to “just work,” it needs to be user-friendly. I believe we have set an industry standard record in our space, but we could do much better still. We believe we are stepping in the right direction with the smaller details, such as whatever happens when you type just a % in your editor (try it, I don’t want to spoil the surprise!)
Lastly, we have dedicated a lot of time, and we will still do, in our product documentation. We have our own in-app documentation center, with access to various product walkthroughs and resource articles.
Our users need more support in growing their portfolio (in a smart way).
We are in a great position when it is about the guest experience, but there are areas where we can be stronger, for example, in everything that is related to the task and team notifications.
Today, we are super excited to release our new product, Operations. It is focused on centralizing Ops communications, with a task-based mindset. This product will enable operation managers to handle any arbitrary number of properties while ensuring consistent and reliable service. Onboarding a new property will also be much easier in the coming months.
Guest experience also needed to scale in a big way. The entire redesign was centered around enabling our customers to reduce the business complexity and scale across platforms, accounts, and properties. With more easily accessible shortcodes and more flexible custom codes, we are still upping our game.
Lastly, I want to say a few words about Metrics. We are super excited about the upcoming redesign of Metrics. In a similar way, we will consolidate the feedback we have gathered to create a platform-agnostic, centralized, Metrics product. The focus will be on delivering a product that supports users in growing their portfolio, without losing efficiency, or losing their sanity. We believe there was already a lot of value in the current mega-release, and we could not wait to show you what we have been up to. We will not forget Metrics (and its cousin product, Market).
Our users are in a multi-channel world.
I came to the world of the short-term rental through Airbnb, and I will always be grateful to this company for the opportunity I had to make ends meet when I needed it the most. This world has now professionalized, with veterans having ten years of experience hosting on Airbnb.
The most exciting development is the upcoming war between channels on taking, or defending, the lion share of the hospitality market. I believe this will be to the benefit of both hosts and guests as it should refocus on product development. There needs to be, however, solutions to address the compounding complexity that it represents.
As was already discussed, the main motivation for the redesign of Guest experience had the capacity to support more integrations with more channels without affecting their onboarding experience.
We have opened Sync to be more flexible than ever, so it can handle any kind of matching. We are also relaunching our Properties product that will be the source of truth for your units, and we are excited to develop a state-of-the-art property management software in the coming months.
Another great area of development that appears quite simple at this point in this article is the fact that you can now push prices and availability on our Calendar, natively and in real-time, to HomeAway and Airbnb, for all your properties. We believe how they should be managed: dead simple, just works.
Building a Saas product is a tale of velocity.
For us, most of the value of this process is to solve all the problems we had, to be able to solve the problems our users have – again. What is more exciting is not what we release today, but what we will have the capacity to deliver tomorrow.
Our new architecture will allow us to integrate with partners much faster. We are looking especially at the Expedia Group (managing HomeAway/Vrbo), and naturally Booking.com in the next few months. We want to consolidate our Properties and Calendar product to simplify the distribution of properties.
We will be releasing our first mobile app within weeks. After many hundreds of questions, we have a clear view than ever about what that mobile app should be.
We will be releasing our API within weeks as well. It’s already being used in production on the new Hospitable, but we want to take just a bit more time to make sure to offer a developer-friendly experience (on a stable infrastructure).
Those are just a few of the things we are working on. More importantly, we hope you will be able to enjoy the many new features and products we are releasing today.
It’s been a tough couple of months with the STR idustry heavily impacted by the pandemic.
Here’s our take on the situation: product development, team management, and next steps.
Saying that engineering the new hospitable was intimidating would be an understatement. The original hospitable is loved by hosts all over the world, so threatening that stability is always a risk.
But, to improve the experience for our customers—as well as to ensure our ability to build the next generation of short-term rental management software—we had to bite the bullet and upgrade. All the things.
When I joined hospitable, I was quite thrilled. It’s not often one gets to work with a platform that’s so loved by its users.
From a technical point of view, the ultimate goal was to design a modular, consistent platform that can grow in time.