State, not decoration
A room is marked arrival-ready only after checking occupancy, maintenance blocks, critical incidents, unfinished tasks and explicit inspection evidence.
TypeScript · Domain rules
← Explore work
PRODUCT / ENGINEERING EVIDENCE
StayOps
Hospitality operations, tested as a connected workflow.
A hospitality software case study covering room readiness, housekeeping, reservation state and the engineering rules beneath a working read-only demo.
Existing product image from the portfolio. Screenshots illustrate the application, not independent proof of production use.
01 / CONTEXTThe problem
The problem
behind the interface.
Hospitality teams cannot decide whether a room is available by looking at a single status field. A reservation, ongoing cleaning, technical room block or unresolved incident may change the actual answer. StayOps models this decision across connected workflows.
Reservation→Check-in→Check-out→Cleaning→Inspection→Ready
02 / ARCHITECTURE
Designed around constraints.
Technology choices are explained through what they protect or enable, rather than listed as logos.
Role-aware operations
Authenticated workflows live in Next.js server actions using a property-scoped Supabase client. Role checks and database policies must both agree.
Next.js · Supabase Auth · PostgreSQLProperty-local time
Readiness calculations follow a property's timezone. Tests include midnight boundaries and the daylight-saving change in Paris.
Intl.DateTimeFormat · Node tests03 / EVIDENCE
What can actually be checked?
No invented clients, invented numbers or imaginary certifications. Each statement has a clear verification boundary.
CLAIMAVAILABLE EVIDENCEBOUNDARY
A working public interface
Read-only workspace and planning routes were reached from the deployed StayOps application.
A read-only demo does not demonstrate privileged writes.
Domain behavior in source
housekeeping-readiness.ts combines reservation, block, incident and task state before a room can be ready.
Actual database context completeness must be checked.
Focused automated tests
On 23 October 2026, GitHub Actions ran the three test suites on a Linux runner: 57 tests passed, 0 failed; TypeScript validation and Next.js build also passed (revision 13891edc).
CI run 40002475017 is recorded in the private repository; independent public review requires repository access. No browser E2E or live database verification was performed.
Documented release risks
The private repository contains specific security, schema, migration and staging readiness reports.
Prior reports noted unresolved staging/production gates; no production security sign-off is claimed.
04 / ENGINEERING HONESTYWhat is not
What is not
proven yet.
- Production database policy and migration parity have not been freshly verified here.
- Concurrent reservations need database-level conflict testing, not only application pre-checks.
- Real signed-in browser scenarios, backup restoration and field adoption require separate proof.
- No hotel client metrics, real revenue improvement or production PMS certification are claimed.
A responsible prototype is explicit about the tests it passes and the production checks it has not passed.
EXPLORE THE ACTUAL WORK
See the rooms and planning in context.
The public demonstration shows actual application screens with synthetic data. Engineering implementation and sensitive infrastructure remain private.