Hospitality Software Was Built for Someone Else

Every tool a hotel or restaurant runs on was designed for a different industry and bent to fit, and that single fact explains almost everything operators hate about their stack.

Hospitality software is a borrowed toolkit, not a category anyone built on purpose. The property management system, the point of sale, the scheduler, the guest database: almost all of it was designed for retail, for generic small business, or for a category that looks nothing like a property at 7pm on a Friday, then sold sideways into an industry that had no better option.

That is why hospitality operations feel stitched together from tools that don't fit and don't talk to each other. The problem was never the operators. It was that almost no one built for them.

What changed is that now, finally, someone can. The reason is not a new idea about hospitality. It is a new number on the cost of building software, and that number rewrites what is worth building.

Key takeaways

Hospitality software is a borrowed toolkit, not a purpose-built category. A retail point of sale here, a generic CRM there, a scheduler designed for warehouse shift work.
Fragmentation is structural, not managerial. Seven in ten US restaurants are single-unit operations, so no vendor ever faced one large, uniform buyer worth building for.
Cost was the whole excuse, and the cost has collapsed. Building the specific thing now takes a small team and months.
Buying more software rarely closes the gap. Suites trade depth for coverage, best-of-breed trades coverage for seams, and consultancies hand you a deck.
The unbuilt category is a studio that builds for the operation on a repeatable line, with equity at risk on both sides of the table.

The morning nobody designed for

Watch a general manager start a shift. The property management system says one thing about tonight's occupancy. The booking channels say another. The point of sale in the restaurant lives in its own world, and reconciling the two is a manual job someone does with a spreadsheet and a coffee.

The scheduling tool doesn't know who called in sick. Guest history sits in four places, none of which agree. By the time the doors open, an hour has gone into making systems that were never meant to speak agree with each other.

That hour has a shape, and it repeats:

Reconcile occupancy between the property management system and the booking channels, by hand.
Reconcile the restaurant against the rooms, usually in a spreadsheet nobody else can read.
Rebuild the roster around whoever called in, in a tool that thinks a shift is a shift.
Guess at the guest, because the history is in four systems and you have time to open one.

None of this is the manager's fault. Each tool, on its own, works. A modern property management system does what it says. So does a good restaurant point of sale. So does a channel manager pushing rates to the OTAs.

The problem is the seams. Every product solves one slice of the operation and assumes the rest of the world doesn't exist. Put ten of them together and you don't get an operating system. You get ten islands and a person rowing between them.

The person rowing is the person running the shift

Here is the part the software industry never priced in. Nine in ten US restaurants have fewer than fifty employees, according to the National Restaurant Association, which means the person reconciling the exports is usually the person who also runs the floor.

There is no integration team. There is no internal platform group deciding which system is the source of truth. There is a manager, a laptop, and a shift that starts in forty minutes.

That hour is not a rounding error either. Do it every morning and it is a working month a year, spent by your best person, producing nothing a guest will ever notice.

Why hospitality got the leftovers

This did not happen by accident. It happened because of how software gets built and who it gets built for.

Software follows money and uniformity

Software gets built first for markets that are large, concentrated, and similar enough that one product fits many buyers. Retail chains. Enterprise back offices. Software companies selling to other software companies. Those markets are easy to build for because the customers look alike.

The vendors that eventually sold into hospitality mostly arrived from somewhere else. Lightspeed grew up in retail point of sale before it had a restaurant product. Square built a payments terminal for anyone with a counter, then extended it toward tables. Neither was wrong to do it. Both were building for the market that existed.

Hospitality is the opposite of uniform

Hospitality is millions of independent operators, thin margins, seasonal swings, and no two properties run the same way. Seven in ten US restaurants are single-unit operations, on the same association's numbers. That is not a market. That is a long tail with a rounding error at the head.

A boutique hotel, a 200-cover restaurant, and a regional group share almost nothing operationally:

The boutique hotel optimizes for RevPAR and a channel mix, so its truth lives in the PMS and the channel manager.
The 200-cover restaurant optimizes for table turns and food cost, so its truth lives in the POS.
The regional group optimizes for the thing head office asked about on Tuesday, which is usually in neither.

Put those three in a room and they do not want one product. They want three, and no vendor was ever going to build three.

A 2x2 matrix plotting revenue per buyer against market uniformity. Retail chains and enterprise back office sit in the high-uniformity quadrants where software gets built first. Hospitality sits alone in the low-uniformity, low-revenue-per-buyer quadrant, which is why nobody built for it.

For decades that made hospitality too fragmented and too low-margin for anyone to build for directly. The industry that trade bodies like the American Hotel and Lodging Association and HOTREC represent is enormous in aggregate and tiny per buyer, which is exactly the shape software vendors avoid.

The industry knew, and said so

None of this was a secret. Hospitality has had a technology profession for decades, with bodies like HFTP convening the finance and technology people who have been arguing about interoperability since long before anyone called it a stack.

The standards work happened. The conference panels happened. What did not happen was anybody with capital deciding that a market of one-unit buyers was worth an original product, because on the arithmetic of the time it plainly was not.

So the industry took what it could get

So the industry did the only thing it could. It took software built for someone else and bent it to fit. A retail POS here. A generic CRM there. A scheduling app designed for shift work in warehouses. Each one a hand-me-down, none of them designed for how a property actually runs a night.

The result is the stack every operator now lives with. Not chosen. Accumulated.

Building the specific thing got cheap

For most of that history, the excuse held. Hospitality really was too fragmented to justify building for it from scratch. Building good software took a large team and a long runway, so it only made sense to build for the biggest and least varied markets. Hospitality never cleared that bar.

That bar has dropped. Hard.

What the collapse in build cost actually means

The cost of building fit-for-purpose software has fallen sharply in the last few years. What used to take a big team and years now takes a small team and months. AI is a large part of that shift, not as a slogan, but as the concrete reason a focused team can now build the specific thing an operator needs in the time it used to take to write the spec.

Read that as an economics story, not a technology story. Nobody has invented a new insight about hotels. What moved is the threshold at which a market is big enough to justify a purpose-built product, and it moved past hospitality for the first time.

The arithmetic that used to say no

Run the old numbers. A team of thirty, three years, an addressable market of buyers who each pay a few hundred a month and churn when the season turns. No investor funds that, and no founder should ask them to.

Now run them again with a team of six and a year. The same market, the same churn, the same thin margins, and suddenly the sum works. Nothing about hospitality improved. The cost of serving it fell.

A bar comparison of build cost in team-years. The old sum is ninety team-years, a team of thirty over three years, which no investor would fund against hospitality's churn and margins. The sum now is six team-years, a team of six over one year, against the same market, which clears.

Notice what did not move in that comparison:

The market did not get bigger. Still millions of independents, still single-unit dominant.
The margins did not improve. Still thin, still seasonal.
The churn did not fall. A property that closes for the season still stops paying.
Only the left side of the equation changed, and it changed by more than an order of magnitude.

That is why this is an economics story rather than a technology one. The same industry that was disqualified for thirty years is now qualified, and nothing about the industry is responsible for it.

The industry that got hand-me-downs for thirty years can now have software built for how it actually works. Nothing about the fragmentation changed. What changed is that fragmentation stopped being disqualifying.

The only question left is who builds it, and how. That question is what the studio exists to answer, and it is the reason we point at one industry instead of ten.

Four seams where the stack actually breaks

Abstractions are easy here, so let us be concrete. When operators describe hospitality software problems, the pain almost always sits in one of four seams, and every one of them is a place where two systems built by different companies for different reasons are being asked to agree.

Inventory and rate

The booking engine, the channel manager and the property management system are each holding a version of tonight. When they disagree, someone oversells a room or leaves one empty. Vendors know this, which is why the fix is usually sold as a marketplace of connectors rather than a shared source of truth. Look at any integration marketplace and you are looking at a map of the seams, not a repair of them.

The guest record

Guest history sits in the PMS, the POS, the reservations tool, the email platform and the loyalty program. None of them is wrong. None of them is complete. So the guest who has stayed nine times gets greeted like a stranger by the one system that happened to be open.

Orders arriving from outside

Delivery platforms, aggregators and direct ordering all push orders at a kitchen that was designed around one screen. Middleware exists precisely because the seam is unbearable, which is what a business like Deliverect is for. That an entire company can be built to translate between systems tells you how badly the systems were designed to speak.

Labor and the schedule

Scheduling tools inherited their logic from shift work in warehouses and retail. They do not know that a Friday service and a Tuesday lunch are different animals, that a section can be covered two ways, or that the person who called in sick was also the only one trained on the till. The trade press covering restaurant operations technology has been writing about this gap for years, and it is still the first thing an operator names.

Four seams, one shape. Each is a place where the operation is real and the software boundary is arbitrary.

Each of those seams is big enough to be its own argument, and the rest of this series treats them that way. If you run tables, the seam map is drawn in more detail in where a restaurant tech stack breaks. If you run rooms, the same failure has a different shape, which is the subject of why hotel technology integration keeps failing. And if you have ever been quoted a number to make two systems talk, what that integration is really costing you is the one to read next.

Buying your way out has been tried

Operators are not passive here. Every one of them has already tried to solve this, and it is worth being honest about why each attempt gets you part of the way and then stops.

The all-in-one suite

An integrated suite is the right tool when your operation is close to standard and you value coverage over depth. One vendor, one bill, one support number, and the seams become someone else's problem. Vendors like Cloudbeds have built real businesses on exactly that promise, and for a lot of properties it is the correct call.

But breadth is bought with depth. The suite's scheduling module is rarely as good as the best scheduling product, and the moment your operation does something unusual, you are back to exports. You did not remove the seams. You moved them inside one vendor's roadmap.

That trade decides more about an operator's next three years than any other software choice, and it deserves more than a paragraph. We take it apart properly in all in one restaurant software versus best of breed.

Best-of-breed plus integrations

Picking the strongest product in each category is the right tool when you have the appetite to run an integration layer and the volume to justify it. Every category has a genuinely excellent option, and the case for choosing it on merit is strong.

The cost is that you now own the seams. Someone has to care when an API version changes, and in a business where nine in ten operators have under fifty staff, that someone is a manager with a shift to run.

Consultants and roundups

Search for the best hospitality software and you will find comparison guides, vendor directories and buyer's roundups, some of them genuinely useful. Publications like Hospitality Upgrade and reference sites like Revfine's hotel software overviews do real work mapping the landscape.

None of it changes the fact that you are still choosing between things built for someone else. A consultancy studies your problem and hands you a deck. A directory hands you a shortlist. Neither hands you software that fits.

Building it yourself

Commissioning your own build is the right tool when you have scale, a technical function, and a process worth encoding. Large groups do exactly this, which is why the systems inside the biggest chains look nothing like the ones sold to independents.

The catch is that a hospitality group is not a software company, and running one inside the other is a permanent tax. You hire engineers, then you manage engineers, then you discover that the roadmap belongs to whoever shouts loudest at the operations meeting. Groups that survive it tend to buy senior engineering judgment before they buy engineers, which is the whole argument for a fractional CTO over a first hire. Coverage of operations technology is full of groups who built something excellent, then watched it rot when the person who understood it left.

Side by side, the four options stop looking like a menu and start looking like one trade priced four ways.

Option	Right when	What you pay with	Where the seams end up
All-in-one suite	Your operation is close to standard and coverage matters more than depth	Depth, and your unusual cases	Inside one vendor's roadmap
Best-of-breed plus integrations	You have the appetite to run an integration layer and the volume to justify it	Ownership of every API change	On the desk of whoever runs the shift
Consultants and roundups	You need the landscape mapped before you commit	A deck, and the time to read it	Exactly where they were
Building it yourself	You have scale, a technical function, and a process worth encoding	A permanent tax, paid in engineers and roadmap fights	Yours, forever, including after the person who understood it leaves
A studio that co-builds	The thing you need does not exist and generic will not stretch to it	Time, access, honesty, and a share of the upside	Designed out, because the operation came before the code

None of the first four is wrong. They are different instruments for different moments, and each one is a rational answer to a badly posed question. The question is badly posed because it assumes the only move available is to choose among things that already exist.

Nobody has built this category yet

The answer is not one more generic tool with a hospitality logo on the login screen. And it is not a consultancy that studies your problem and hands you a deck. Operators have both already. Neither closes the gap.

The missing thing is a studio that builds software for hospitality operations, the guest, the workforce, the property, and builds it on a repeatable line. Not a single product and a hope. A method applied venture after venture, each one designed for the operation from the first line of code, each one built alongside the operators who live the problem.

That category needs a name and a shape before it can be argued about, which is what a hospitality management platform built for the shift sets out to do.

Software that fits because it was made to fit, by people who put their own outcome on the line next to yours. That is what our equity model is for: we sit on the cap table rather than send an invoice, so a product that does not work is our problem too.

Why almost nobody is doing it

That category has been possible for about as long as it has been affordable to build the specific over the generic, which is to say, not very long. Everyone who could build it has a reason not to:

The vendors already in hospitality are defending installed bases, and a purpose-built rival is a threat to the roadmap they have already sold.
The studios that could build it are pointed at fintech, where the uniformity is better and the margins are kinder.
The operators who understand the problem best are running the shift, which is precisely why they have no time to fix it.

Building for one industry and staying there costs you the nine industries you did not pick. We take that trade on purpose, and how we choose what to build is downstream of it.

What this looks like when it works

A method is only worth anything if it produces something an operator can use on a Tuesday. So here is the shape of a build when the line is running properly.

Validation before code

It starts with the operators, not the roadmap. Fifty or more real customer interviews in the first six weeks, with the people running the shift, the floor, the front desk. Assumptions are cheap and usually wrong, and the fastest way to lose a year is to build the thing everyone agreed sounded sensible in a meeting.

A real product in a real property

Then the build. Real users on the product by month three, running in an actual property, doing an actual job. Investor-ready or an honest pivot by month four, because a slow no is more expensive than a fast one.

Speed matters more than polish at this stage. A working product that teaches you something beats a perfect one that ships after the season it was meant for.

Skin in the game, on both sides

The commitment is specific on both sides:

The operator commits time, access, honesty, and a willingness to change how things are done.
We commit our building, our people, and our equity, which means we only win if the venture wins.
Neither side can quietly lose. There is no version of this where we get paid and walk away from a product that did not work.

For an operator, that is the safety in the arrangement rather than the risk in it. You are not hiring a vendor who is finished when the invoice clears.

The line, not the one-off

Then it repeats. The Gourmet Host is on the line. So is Onbi AI Mentor, which sits with staff training and operational mentoring, and PropTech KSA, built for how property actually works in the Saudi market. Agentic reception is next, then a guest experience layer.

Each build teaches the next. The shared infrastructure carries forward, the playbook carries forward, and the knowledge of how this specific industry behaves carries forward, which is the part a generalist cannot copy.

What the operator gets is software that assumed their shift existed. What the industry gets, eventually, is a category.

Where this goes next

Naming the problem is the easy part. The harder part is the method: what a line that builds hospitality software actually looks like, why a studio beats an agency, and what it means to put cash and equity at risk on both sides of the table.

That is the next chapter. This piece is chapter one of three, and the argument only pays off if you follow it through the second, where the method gets taken apart properly, and the third, where a real build gets walked start to finish.

If you run hospitality operations, or you invest in the people who do, this is the argument worth following from the start.

Frequently Asked Questions

What software is used in hospitality?

Hospitality runs on a property management system, a point of sale, a channel manager or booking engine, a scheduling tool, and some form of guest database. Hotels lean on the PMS. Restaurants lean on the POS. Almost every one of those categories was invented for another industry first, then adapted for hospitality afterwards.

Why is hospitality software so fragmented?

Because software gets built first for large, uniform markets where one product fits many similar buyers. Hospitality is millions of independent operators with thin margins, and seven in ten US restaurants are single-unit operations, which for decades made it too fragmented to build for directly. Operators adapted tools built for other industries instead, and the disconnected stack is the result.

What is a CRM in hospitality?

A hospitality CRM stores guest records, stay or visit history, preferences and marketing consent, then uses them to personalize service and drive repeat bookings. In practice the guest record is split across the PMS, the POS and the booking channel, so the CRM usually holds a partial copy rather than the truth.

What does fit-for-purpose hospitality software mean?

Software designed from the start for how a property actually runs, across guest experience, workforce and property operations, rather than a generic product bent to fit. Fit-for-purpose software connects instead of creating islands, and it reflects the real workflow of a shift rather than a workflow borrowed from retail or warehousing.

Which software is used in Hilton hotels?

Large chains typically run proprietary or heavily customized systems built for themselves, which is the whole point. Scale buys you the option of commissioning software that matches your operation. Independent operators, who make up the bulk of the industry, have never had that option and have taken hand-me-downs instead.

How has the cost of building hospitality software changed?

It has fallen sharply. What used to require a large team and years now takes a small team and months, largely because of advances in how software gets built. The economics that once made building for a fragmented industry impossible have changed, so the long-standing excuse no longer holds.

Continue Reading:

More In This Series:

More from Teleport Dynamix:

Explore the Insights Categories: