Complexity is the one thing a software team can always produce more of. Each new feature or automated step is something a hotel team has to learn and then trust. Earn complexity, one of our four principles, sets the bar for adding any of it. Our reading is simple: build the smallest system that does real work, then extend it only when the operation gives a clear reason.
Simple first
The principle comes with its own sequence: start with a focused problem, learn from actual use, extend the system when there is a clear reason. The order matters. A focused problem can be understood well. Use then shows which parts of the solution matter and which were guesses.
Simple first does not mean a toy. It means the smallest version that does real work for a team during an actual shift. A narrow tool that a front desk opens every day teaches more than a broad one that nobody opens at all.
Starting small also keeps the system legible. When a product does a few things, the people using it can say what it did and why. When something goes wrong, they can find the cause without calling an engineer. That clarity is hard to recover once a product has grown past what anyone can explain.
Complexity has to pay for itself
Every addition carries a running cost. An integration has to be kept in step with the system on the other end. A setting has to make sense to whoever inherits it at the next handover. A new screen competes for attention with every screen that already exists.
Interface is the easiest place to see this. A new tab or setting is cheap to add and hard to remove, because someone usually comes to depend on it. Another of our principles, build for outcomes, not more tabs, is partly a defense against that drift.
So each addition has to pass a plain test. It must answer a need the operation has actually shown, rather than make the product look more capable. If the reason is speculative, the addition waits.
For example, staff might copy the same detail from one system into another at every handover. That repeated, visible effort is a clear reason to connect the two systems. A connection built because it might be useful someday is not.
Complexity that passes the test is welcome. A hotel is a complicated place where departments hand work to each other all day. A system too simple for that fails the people using it. What we avoid is complexity that arrives ahead of the need, built for a case nobody has met yet.
Autonomy is earned too
The same rule governs what an agent is allowed to do. Autonomy is a form of complexity, probably the most expensive one. A mistake made by software acting alone can reach a guest before anyone sees it. In a hotel, that guest may be standing at the desk when it happens.
Drafts come before actions for that reason. Guester AI prepares drafts of review responses for the hotel to approve. A draft is cheap to correct, while an action already taken is not. Where an agent does take on more, it stays inside whatever permissions and approvals the hotel has put in place, as described in who stays in control when agents act.
A wider scope is earned the way a feature is. The narrower scope has to work first, in actual use, for the people who depend on it. They also have to be able to see what the agent did and why, or they have no basis for trusting it with more. Only then is there a clear reason to extend it.
Building above, not instead
The largest piece of complexity a software company can ask of a hotel is a replacement. It asks a team to give up tools it already knows, along with the habits and workarounds that made them usable, before any new value appears.
We take the other route: a layer above the systems a hotel already runs, where agents work through that infrastructure instead of around it. The full argument is in one layer above the software you already run.
Seen through this principle, the layer is the cheaper kind of complexity. It adds one thing a hotel team has to understand instead of replacing many things it already understands. If the layer does not make the operation easier to run, that is easy to see, because the systems underneath keep working without it.
A system built this way grows in the order the operation asks for things. Each part arrives with a reason a hotel team has already seen for itself. Nothing in it is waiting for a case that never came.
