Most vacation rental operators on Streamline have the same website. Not literally the same, but the same shape: the vendor's template, the vendor's booking widget, the operator's logo in the corner. It works. It also looks like the operator down the road, and every change goes into a queue that belongs to someone else.
This summer we built a direct booking website for a ski-destination operator with a few thousand homes, on top of Streamline, without replacing it. Streamline still runs their reservations, their rates and their owner accounting. It is still the system of record. What changed is everything the guest sees.
People in the industry told us this is unusual for a firm that is not a Streamline partner. It is less unusual than it sounds. It comes down to two decisions made before the first page was designed.
Decision one: the website never talks to Streamline
The obvious design is to have the website call the PMS for each page. Search page, call the API. Property page, call the API. Booking, call the API. It is how most integrations start, and it is the reason most of them are fragile.
A property management system is built for property managers, not for a public website with real traffic. Its job is the reservation feed, the price quote a guest is waiting on, the payment going through. A website that leans on it for every page view competes with that job on the busiest day of the year.
And every mature PMS, any vendor, has its own way of doing things: its own field shapes, its own conventions, its own limits, learned over years of serving thousands of operators with different needs. That knowledge belongs somewhere. It should not belong to the website.
So we put one service between the two. It is the only door to the PMS, in both directions. The website reads from that service and only from that service. The service owns the vendor connection, the pacing, the retries, the tidying of every record, and everything that gets stored. The website is presentation and intent: show the homes, take the search, capture the booking request. The service does the rest.
Two things follow from that.
The website gets fast, because it reads from a local copy that is current within minutes rather than waiting on a vendor round trip for every click.
And the operator gets a layer they own. If they ever moved from Streamline to Guesty or Track, the website would not change. The adapter behind that one door would. That is not a hypothetical we put in a slide. It is how the service is built.
Decision two: secrets never enter the building
A property record from a PMS carries things a public website must never hold. Lock box codes. Wi-Fi keys. Owner and vendor identifiers. The whole record is available to an integration, because the PMS was built for the people who need those things.
The tempting design is to store the whole record and filter on the way out. Keep everything, show only what is safe. It is tempting because it is easy, and it is wrong because every filter is a thing someone can get wrong later, in a hurry, on a Friday.
We did the opposite. The service builds each home from a named list of fields and never carries the raw record. A lock box code cannot enter the store, because nothing ever copies it in. There is no filter to maintain. There is nothing to leak.
The same posture applies to payments, where the stakes are higher. The website never sees a card number. The payment provider captures it in its own hosted flow and returns a token and a status; that token is what the PMS receives. Card data cannot leak from a system it never enters. The operator's PCI scope stays where it was, with the provider and the PMS, and does not grow because they got a better website.
What the operator keeps
Streamline's role in this picture is a good one, and it does not shrink. It does the operational work it was built for: inventory, rates, reservations, owner statements, the things a PMS does well. Nobody in the operator's office had to learn a new system.
What the operator gains is a layer above it that is theirs. A website designed for their brand and their destinations, on their real inventory. A local, tidy copy of their own data that their CRM and their reporting can read without asking the vendor. Every account, domain and line of code in their name.
If you are on Streamline
You do not have to leave Streamline to have a website that is yours. You need one service that owns the vendor connection and everything it knows about that connection, a discipline about what that service is allowed to hold, and the willingness to let the PMS remain the system of record while your own layer grows above it.
If your public site is the template, we can show you your own homes on a site built for your brand in a few days. That is where every engagement of ours starts.