1) What is your stack?
The front end, or what you see when you log in, can look amazing and modern—
but it doesn't tell you what the software is built from or how good it is.
By getting an idea of the efficiency 'beneath the hood' based on the programming languages used, its framework, and what platform it's being hosted on, you'll be able to assess whether the platform is worth your time.
In layman's terms, a stack is the main set of programs, services, and languages on which a system operates. Knowing this is important as there are an endless variety of ways they can be combined.
Each also has their own set of pros and cons.
As a general rule, if services are being used that haven't been updated since the nineties, chances are high the software will be less powerful and slower than other, more recent, services.
2) What is the company's software background?
The answer to this question will tell you a few things:
a) how steep your learning curve will be,
b) how much care was taken in building the software, and
c) how seriously your feedback will be taken.
If the system was built by engineers with no outside feedback, then you know that the backend of the software will probably be beautiful...but the front end, where you live your day to day, will be harder to navigate. Chances are high it won't be as intuitive, and you'll need to pick up some tech experience to get the hang of the system.
If the software was dreamt up by those with no software background who then outsourced the programming, your experience may be the complete opposite: the front end will be beautiful, but chances are high the software will lack the necessary functionality you need to accomplish your operations.
A happy medium is best. One where there is hybrid of those with a deep understanding of writing code, and also those who understand product and its design. That way you know the back end is solid, while your day to day experience in the front end is effortless.
A hybrid will also be far more open to client experience and suggestion. From an engineering perspective: just because something isn't intuitive doesn't mean it's broken. So if it works, why fix it?
Making sure the company environment is one where both of these elements work together means not only will the software be higher quality, but your experience using it will carry weight...and really the client's experience is the most important part. What good is software if people don't want to use it?
3) Did you build your own features/products, or did you acquire them?
Many vacation rental software platforms were not one system to begin with.
Often, a platform will evolve from one company acquiring another, or their service. For example, a software company could say that they are a PMS, a channel manager, and a housekeeping system. However, that platform may have started out as a PMS, which then bought a channel management company and a housekeeping system. This is important as it means each system is being made to connect, but they were not designed to do so. Being able to connect different systems reliably depends on the software's stack. In many cases it's possible...but it's not always pretty.
More hoops to jump through means the software systems:
a) run more slowly, and
b) have more opportunities for bugs, or problems.
Slow software with a lot of bugs heavily detracts from your experience as the user, especially when those bugs mean a double booking or an incorrect reservation. It’s true that all software will have bugs, and many systems can work together well; however, problems are less likely/frequent if the systems were designed to work together in the first place.
How does this affect you? Integrations, or the systems speaking back and forth to one another, are more prone to breaking when the connection is patched together. This is because the two software systems have to jump through multiple hoops in order to speak back and forth.
4) What channels do you integrate with via their official, or authorized, API?
Speaking of software communicating, let's touch on APIs. As #1 mentioned, a stack is the programs and languages the software is built with. An API is essentially how the software communicates with other systems. It's the connecting point. So when someone says "I need to see your API prior to integration", or "you can build to our API", what they're saying is: "I want to see how your software communicates with others", and "we're cool showing you how our system communicates, so you can build something that connects with ours perfectly". This is where the 'official' or 'authorized' distinction comes in, and it’s incredibly important.
An official API connection means the softwares are speaking back and forth using an integration that is well-maintained and sanctioned by the individual software companies.
This means if something breaks, both companies will try to restore the connection as quickly as possible. If software is connected to a channel without an authorized integration, that means they're connecting to the channel using code that is not part of the official API. One company has found a way to connect to the other using random, publicly available pieces of their code. This is incredibly risky, as code is often updated.
In order for systems to connect, their code needs to fit together perfectly. A good way to visualize this is a lock & key. Each groove of the key needs to match the lock in order for it to open. If code is updated, the grooves will no longer match, and the connection between the systems will be severed. It will also take longer to re-establish the connection. The channel doesn't care; they didn't sanction the connection, so they're not going to help try and fix it. It will be the sole job of the software company to find a way to build to the channel's updated code so your listings will be live again. Until that point, you're likely to get a double booking as the channel can’t tell the PMS if reservations, or any updates, are being made. In a nutshell- unless there is an official API integration, using that connection is extremely risky.
5) If I use your software, who will I be working with?
This question helps you define how important navigating that fix is to the software company: essentially how important your happiness is to them. Solid support is necessary during onboarding, however it needs to be ongoing. Incorporating vacation rental software into your operations means you're going to start incorporating the people who work there as well. If the people you speak to are not well versed in tech, or this question is brushed off with "we have a 24hr call center", that’s a big red flag.
Despite having a modern stack, built by a great hybrid of individuals, with seamlessly connecting internal products, and all official API integrations...things are going to break. Such is the nature of code. Fixing things is sometimes as simple as refreshing an application, and other times it requires extra coding.
You need a clear answer as to who you would contact when a significant bug pops up. Having a seamless transition between the sales representative and your onboarding specialist/account manager shows that your business & inventory are a priority.
Searching for software can be daunting, especially when it's fraught with steep learning curves and the inevitable bug. Asking these questions will help you sift through any misleading marketing or technical jargon so you can get the important details quickly!
And, at the end of the day, if you're happy, then you picked correctly.