Hospitality
Housekeeping boards for a small hotel
A forty-room hotel assigns rooms to housekeepers each morning based on checkouts and stayovers. Housekeepers mark a room clean from their phone and report a maintenance problem. Reception sees in real time which rooms are ready to check in.
Automatically generated draft
Written by machine against our own engineering playbook. The company is invented; the decisions are the ones we would make on a real build. A reviewed blueprint goes further — nine sections, agreed line by line, and it is what the build is tested against.
Section 01 · What has to work
Housekeepers must be able to mark a room clean from their phone and have reception see it instantly so check-in can proceed without a radio call.
Section 03 · Screens
Every screen, and what it is for.
- ›Room Board — Reception views real-time room statuses, must be instant.
- ›Morning Roster — Housekeeper views assigned rooms, must be instant.
- ›Room Detail — Housekeeper marks clean or logs issue, must be instant.
- ›Maintenance Log — Reception views and resolves open issues, must be instant.
Anything not on this list is not in version one. That is what keeps a fixed price fixed.
Section 04 · The data model
What it stores, and who can read a row.
rooms
id uuid, number text, status enum(dirty, clean, maintenance, inspected), floor int
Access · All authenticated hotel staff can read all room rows.
assignments
id uuid, room_id uuid, housekeeper_id uuid, work_date date, status enum(assigned, in_progress, completed)
Access · Housekeepers read own rows; reception and managers read all rows.
maintenance_issues
id uuid, room_id uuid, reporter_id uuid, description text, priority enum(low, high, urgent), reported_at timestamptz, resolved_at timestamptz
Access · All authenticated staff can read and create issues.
Those access rules belong in the database, not in the screens. Someone who edits the address bar still cannot read a row that is not theirs — and the test that proves it blocks delivery if it fails.
Section 05 · States
dirty → in_progress → clean | maintenance → inspected
Most scope arguments three weeks into a build are really arguments about a state nobody named at the start.
Section 06 · Where this breaks
What bites products like this one.
Housekeepers working in concrete stairwells lose cell signal and will not be able to submit room status updates.
Queue status changes locally in IndexedDB and sync automatically when connectivity returns.
Reception and housekeeper update the same room status simultaneously, causing a race condition.
Use database row-level locking and optimistic concurrency checks on room status changes.
Section 08 · Deliberately left out
What version one does not do.
- ×Automatic algorithmic room assignment based on checkout times — manual assignment by reception is simpler, adding it takes three days.
- ×Photo uploads for maintenance issues — storing images inflates storage and bandwidth costs, text descriptions are enough for v1.
This is the section that protects the date, and the only place in the document where somebody says no. It is also why clients trust the rest of it.
Still open
What we would ask before quoting.
- How does reception handle rooms that require deep cleaning versus standard turnarounds?
- Do housekeepers need to see past cleaning history for a room, or only today's assignment?
Half of this already exists
Fieldline
The field half of this is a solved problem: routes assigned, work captured with no signal and synced later, and an alert when nobody shows up.
It is one of our pre-built products: the code is handed over to you, adapted to your own wording and rules, and the rest of the specification above is built on top of it rather than from scratch.
Your product, not this one
Get this written for what you are actually building.
Describe it in a sentence and the generator returns the same sections for your own product. Free, no email, nothing saved to a list.
Next step
Find out if your idea fits in 10 working days.
Tell us what you want to build. We reply the same day with a straight yes, no, or here is what we would cut.