The Problem
An independent hotel runs on three departments that share one asset, the rooms, but no shared system. Front desk sells them, housekeeping turns them, maintenance fixes them. Coordination happens over radios, paper checklists, and someone walking upstairs to check. Where software does exist it is dispersed, a tool per department, and those tools do not communicate. None of them can tell you the current state of the hotel.
So the managers are not using systems. The managers are the system. Every question about a room’s real state routes through a person, and if one of those managers leaves, a chunk of the hotel’s knowledge walks out with them.
Enterprise hotel software exists, but it is priced and built for chains. What boutique hotels get instead is that pile of disconnected tools, or lately, chatbots that answer questions about operations without being able to do any operations. Lush is the answer to a different question: what if the entire operation ran on one platform, and an AI agent could work it like a manager does?
The Solution
Staff carry a mobile application showing a prioritized list of the rooms they need to handle. They tap start, do the work, tap complete, and move to the next room. Every status change syncs in real time to a managerial board where housekeeping, maintenance, and front desk see the same truth. Managers can work the board directly, or tell Lizzie, the platform’s agent, to do it for them. Lizzie reads the request, takes action through the same permission layer a manager uses, and reports back. Underneath both of them, deterministic code enforces what is allowed to happen to a room and in what order.
Solution Highlights
An agent can only take real action in a system built to be acted on.
Most hotel AI is a chatbot bolted onto someone else’s property management system, which means it can read but not reliably do. I built the operating platform from the ground up specifically so the agent would have full control of the structure underneath it. Every workflow the agent can touch is one I designed, coded, and constrained. That is the whole thesis of the product: the intelligence is only as trustworthy as the system it operates.
The hard work was decomposition, not code.
Before writing the platform I shadowed the three people who actually run a hotel: the housekeeping manager, the guest experience manager who runs the front desk, and the head of maintenance. Then I broke everything they and their staff do into discrete processes, and built each one as deterministic code with explicit checks on what must be true before a step can happen. There are too many processes at this point to count, so here is the one everything else hangs off of.
Room turnover is the spine of a hotel, so it became a state machine.
A vacant room moves through four states: needs cleaning, inspection ready, inspected, or needs maintenance. The distinctions carry real operator knowledge. A room that is out of order cannot be rented; a room that is out of service still can. Priority is a human judgment, not a computed guess, so managers mark rooms critical, rush, normal, or delayed and the staff queue orders itself accordingly. The housekeeping manager performs inspections. Any staff member can flag a room to maintenance, and maintenance categorizes the problem from there. None of these transitions can be skipped, by a person or by the agent, because the rules live in code.
Lizzie is a manager, not a superuser.
Lizzie can do anything a manager can do in the application, and nothing a manager cannot. She is not a special channel into the database. If the deterministic layer blocks a manager from an action, it blocks her identically. A manager can hand her the busywork, reprioritizing a queue, updating room states, creating work orders, and trust that she physically cannot break the operation, because trust is enforced, not prompted.
What did not work: she did not speak hotel.
Early on, a manager could tell Lizzie “room 214 is not working” and she had no idea what that meant. Should she create an issue, open a work order, mark the room out of order, or out of service? No deterministic check can resolve that, because the ambiguity lives in human language, not in system state. The fix was a vocabulary guideline in her system prompt mapping how operators actually talk onto the objects the system knows. The rule I took from it: constraints belong in code, judgment belongs in the prompt, and the prompt is where you encode your understanding of the user.
The honest status: built, ready, and waiting for its first hotel.
Lush has never run inside a live property. Eleven months of building produced a complete platform, and the months since have been pure sales, which has proven the harder problem. I am currently looking for a hotel willing to take the chance, and the design partner program exists exactly for that: I come on site, audit the operation myself, and run Lush side by side with the current process so the team sees the impact instead of hearing about it.
Cost and build time
Running cost
Fixed costs today are about $60 a month, assuming pre-launch usage on shared infrastructure. Model calls are where the real expense lands.
- Database: a small Postgres instance on AWS RDS, db.t4g.micro on the default tier, about $20 a month. Hotel operations data is small. A property generates a few thousand rows a day, so storage is never the constraint.
- Hosting: Railway and Vercel, about $20 a month each, not dedicated. That covers the ops backend, the analytics backend, the manager board, the staff app, and LushLytics.
- Auth: free at this scale, and it stays free well past the point where a single hotel’s staff would need it.
- Model calls: the real lever, and it scales with how much managers hand to Lizzie, not with how many rooms exist.
How it scales
Every property added is projected to raise the monthly bill by about 100 percent of today’s fixed cost, roughly $60, and almost all of that is tokens. The reason is that infrastructure is shared across properties and tokens are not. Two hotels run on the same containers and the same database instance, and one more property’s rows are a rounding error against a db.t4g.micro. But every manager talking to Lizzie spends tokens no other hotel shares, so model spend tracks the number of managers using her and is the only line that grows one for one. The infrastructure lines only step up when connection counts and SSE fan-out force a dedicated setup, which is a problem that arrives at ten properties, not two.
Build time
Eleven months, part time, one person, covering the platform, the staff mobile application, the managerial system, the analytics product, and the agent.
Working on something like this?
I build full stack AI systems for companies that want to improve how they work or do things that were not possible before. Lush is a hotel product, but the method is not. Shadow the operators, decompose the work into deterministic processes, then put an agent on top with exactly the permissions a human has. That translates to any operations heavy business. If you are working on this kind of problem, message me on LinkedIn or shoot me an email. Let’s see what we can build.
Want to see the product first? Visit lushtech.net.
Syd Reynoldssydreynolds@merceng.com