Build with a partner: the third option in build vs buy hotel software

The vendor demo ends and the room splits two ways. Half the table wants to write a check to the SaaS company and be done by Friday. The other half wants to hire a dev shop and own the thing outright. The COO sits in the middle, because both camps are about to be wrong in expensive, opposite ways, and she already knows it. She has bought the box that could not hold her portfolio. She has funded the custom build that nobody could maintain after the engineer who wrote it left.

We have been on every side of that table. We wrote an honest build vs buy framework for hospitality data, and most operators who read it landed on “buy,” which was the right call. But the framing that survives every one of these meetings is simpler and harder than build vs buy. Build vs buy is a false binary. The third option is build-with-a-partner, and it is the one nobody puts on the slide.

Why build vs buy hotel software is the wrong question

The two named options are really two failure modes wearing nice clothes.

Buy means a SaaS box. For a single brand at five or fewer properties, the box is usually correct, and we will tell you so without an invoice. But at portfolio scale the box hits a ceiling. It imports your segment logic once and never looks back. It cannot reconcile a corporate buyout against a social wedding at the same average check. It does not know that your catering pace out of Tripleseat behaves nothing like your transient pace, because no packaged forecasting tool was built for the way banquet revenue actually books. The box is not wrong. It is just built for the median operator, and a 15-property, two-brand portfolio with a custom F&B concept is not the median.

Build means a custom system you own. It fits perfectly on day one. Then the revenue manager retrains the forecast, the catering team adds a market segment, the chef rebuilds the bar program in Toast, and the asset manager wants gross operating profit by segment that the original spec never contemplated. Nobody at the property has time budgeted to maintain any of it. The system that fit perfectly in February is eleven points off the board pack by July, and the engineer who could fix it is at another company now. A custom build is a maintenance contract you signed without reading. We wrote a whole piece on how those builds die. They die the same way every time.

So the real question is not “build or buy.” It is: who owns the layer where your systems disagree, and who keeps owning it after launch.

What build-with-a-partner actually is

Build-with-a-partner is not a third vendor category. It is a posture. You keep buying the commodity layers, because a vendor will out-invest you on those every year for the next decade. You keep your packaged revenue management system, whether that is IDeaS or Duetto or whatever your brand mandates. You keep Lighthouse for comp set. You keep the brand’s BI portal for property-level operational reporting on top of Opera or OnQ. None of that is the work.

The work is the thin intelligence layer on top, the one that reconciles those systems into a single source of truth and reads the way an operator already thinks. Not another dashboard. A connected layer that defines revenue once and serves the same number to the owner monthly, the board pack, and the Monday ops call. The reason a partner builds it instead of a SaaS company is that this layer is made entirely of judgment calls about your portfolio’s economics. Which cover count is the real one when the chef counts seats, the F&B director counts entrees rung in Toast, and the catering office counts contracted heads in Tripleseat. How catering pace gets forecast when it does not behave like transient. How owner reporting maps to your specific management agreements. A box cannot ship that because it cannot know it. A pure custom build can ship it once and then rot, because the judgment leaves when the engineer leaves.

The partner difference is that the judgment stays. We sit in two Monday ops calls and one quarter-end review before writing a query, because the definitions are the asset, not the code. We write a data contract in plain English for every metric, the kind a DOSM or VP F&B can read and argue with. Then we maintain it against the segment recode, the menu reset, the PMS conversion, and the three leadership turnover events that hit every portfolio in year two. The boring layers you bought stay bought. The judgment layer is the partnership. This is the same pattern at the root of why five systems give you five different revenue numbers: the disagreement is not a software bug you can purchase your way out of, it is an ownership gap, and a layer on top is what closes it.

When each of the three is actually right

Here is the honest cut, because a partner who cannot tell you to walk away is just a vendor with a longer sales cycle.

Buy when you run one brand at five or fewer properties, your F&B maps cleanly to banquet, restaurant, in-room dining, and bar, and your ownership accepts brand-template reporting. The brand portal already covers most of what your GM opens on a Monday. Spend your money on configuration, training, and adoption instead. A GM who actually opens the tool every week beats any layer we could build. We mean this. Roughly one in three operators who call us should buy and skip us, and we send them a short list and end the call.

Build in-house when you have a genuine engineering org with permanent capacity, your needs are so specific that no partner has a head start, and you can fund maintenance forever as a line item, not a project. This is rarer than people think. Most operators who choose pure build are really choosing “buy a contractor and hope,” which is the worst of both worlds: custom cost with vendor abandonment. If you cannot name the two humans who maintain it in year three, you are not building, you are accruing debt.

Build with a partner when packaged software has hit its ceiling but you do not want to stand up an engineering department to clear it. Ten or more properties, two or more brands, owner reporting that goes past templates, F&B that does not fit standard buckets, and the same number disagreeing across systems every month. You need the commodity layers (buy those) plus a maintained judgment layer on top (build that, with someone who stays). That is most real portfolios. It is also the case nobody puts on the demo slide, because no single vendor sells it.

Where this fits in the operator intelligence model

The third option is not a clever procurement trick. It is one move inside a larger model, the one we keep coming back to. Build the operator intelligence layer on top of three things. One connected source of truth, so the owner monthly, the board pack, and the ops call all read the same number. An intelligence layer that reads the way an operator already thinks, in covers and segments and pace, not in raw warehouse tables. And an operating cadence that turns it into a daily habit instead of a quarter-end fire drill. Build-with-a-partner is simply how you assemble that layer when you are too big for the box and too lean for an engineering department. You buy the floor. You partner on the part that holds your judgment.

You can do this yourself. Buy the commodity layers honestly, write the data contract in plain English, name an owner for every number, and fund the second ninety days harder than the first. The steps are not secret. Or we build the judgment layer with you and stay on it through the year-two changes that kill the systems nobody maintains. Either way, the build vs buy fight in that conference room was the wrong fight. The right one is who owns the layer where your systems disagree, and whether they will still own it next year. See what we do. Then go pick the option that is actually yours.

Peter Hough is co-founder of Hospitality Data Solutions. Twenty years in hotel and restaurant operations, now building the systems we wished we had.