The middle is the problem

A reasonable feature list can hide an unclear customer

Here is a pattern in hotel software, especially in the hotel property management system (PMS). The feature list looks reasonable. You can see why someone asked for every item on it.

That's the problem. The product is trying to serve a small property and a large hotel group at the same time. It asks the small operator to learn too much and leaves the large operator with too many open requirements.

No single feature is missing. What's missing is a decision about whose working day the product should make easier.

For a small hotel PMS, start with inventory, price and cash

The guesthouse or homestay owner asks three things every day: what rooms do I have, what am I charging, and did the money come in? Inventory, price and cash.

Some small properties do have complicated distribution or reporting needs. Fine. The default experience should still fit the operator you chose, not every operator you might sell to someday.

An owner who runs the place from a spreadsheet already has a way to answer those questions. Switching costs them time to learn. If the first screen is a maze of settings, you've just handed them a reason to stay with the spreadsheet. A longer feature list makes the sale harder when it makes the first day harder.

Nobody decides to build for the middle. It happens one reasonable feature request at a time.

The large group needs depth behind the screen

At the other end, the requirements change. A multi-property PMS needs group-wide controls. Integrations, permissions, finance workflows, implementation and support all have to fit how the group actually runs. Having a feature on the list doesn't mean it's good enough.

We built from scratch a cloud-native hotel PMS that scaled to hundreds of hotels, and the investment ran into millions. That's what it took us to build for that level of complexity. It isn't a price tag for every hotel software project.

Adding one enterprise request a month won't slowly add up to an enterprise-ready business. The work is in how the product gets deployed, maintained and supported, not only in what shows up on screen. It's also why so many hotels would rather not replace their PMS at all.

The middle is a design failure, not a room count

Plenty of good businesses serve mid-sized hotels. We're not saying anyone should ignore that part of the market.

The middle we mean is a product whose promises conflict: simple enough for an owner with a handful of rooms, deep enough for a group, and somehow cheap to serve in both cases. Without a deliberate definition of the customer, every reasonable request pulls the product a different way.

So each request should come with context. Which customer needs it? How often? What do they do today without it? Does it make the product better for the segment you chose, or does it make your existing customers work around someone else's requirements?

Make the segment visible in the default experience

Pick the segment first. If it's small operators, the opening screen should make inventory, price and cash obvious. Put the less frequent features behind deliberate settings and bring them up when they become useful.

Hiding a complicated workflow doesn't help if the owner still needs it to finish a basic task. The product has to stay simple through setup, through the daily routine, and on the day something breaks.

The test is practical. Can a new customer do the important work with little explanation? Can the business support that customer at the price it charges?

You can broaden the product later. First, be clear about who should choose it today. Nobody decides to build for the middle. It happens one reasonable feature request at a time.