A hotel's worst night is not a bad review. It is two guests standing at the desk at eleven, both holding a confirmation for room 12.
That failure is what Stayvieo was built to make impossible — and the reason the architecture looks the way it does. This is the story of what we found in independent properties, the one decision the whole system rests on, and what it looks like now that real hotels are running their arrivals on it.
The problem nobody names
Walk behind the desk of a fifteen-room independent hotel and count the places a room can be sold.
There is Booking.com, in a browser tab. Airbnb, in another. Expedia, probably. The property's own website, which takes bookings by email. A phone that rings. And a spreadsheet — sometimes a paper diary — that is meant to be the master record, updated when somebody remembers.
Every one of those tools works. That is what makes the problem so easy to miss. The failure is not in any one channel; it is in the space between them:
A room sells on one marketplace, and the count on the other two is now wrong until somebody logs in and changes it.
Rates get raised for a bank holiday on three sites and forgotten on the fourth, which quietly sells the weekend at February prices.
A guest messages on one platform, a different guest emails, a third texts the number on the confirmation — and nobody can see the conversations in one place.
The spreadsheet disagrees with the channel dashboards, which disagree with each other. On a busy week, nobody is confident which is right.
Every one of those gaps costs money, and none of them appear on an invoice. Some of it is rate leakage — rooms sold cheaper than they should have been. Some of it is time: a manager doing twenty minutes of copy-typing a day to keep four calendars in step. And occasionally it is the eleven o'clock problem, which costs a relocation, a refund and a review.
The bet we made
Stayvieo's hypothesis was blunt: if availability exists in exactly one place, the class of problem disappears.
Easy to say. The difficulty is that "one place" has to be reconciled with thirty-odd marketplaces that each believe they hold the truth, each with a different API, a different vocabulary for the same concepts, and a different opinion about what should happen when two updates collide.
Building a calendar is a weekend. Building a calendar that is genuinely authoritative across thirty channels — where a booking taken on Airbnb at 22:41 has closed the room everywhere else before the confirmation email lands — is a different order of problem. That is the part that took the work.
The idea the whole system rests on
There is one architectural decision underneath everything else, and like most of the ones that hold up, it is almost embarrassingly simple.
The room-night is the unit, and there is only ever one of it.
Not "availability on Booking.com" and "availability on the website" and "availability in the diary" — one record for one room on one date, in one ledger. Every channel is a view of that ledger, never a copy of it. A reservation, wherever it came from, is a claim on specific room-nights, distinguished by a source field and nothing more.
That single decision is what makes the rest possible. There is no reconciliation step between channels, because there is nothing to reconcile. Rates are set once against the ledger and pushed outward. The front-desk calendar is not a report assembled from four systems — it is the system. And the double-booking case stops being a race between marketplaces and becomes an ordinary write conflict on a single row, which is a problem databases have known how to solve for forty years.
What we built
On top of that ledger sits the property:
A drag-and-drop front-desk calendar. Move a booking, extend a stay, block a room for maintenance — the ledger changes and the channels follow, not the other way round.
Two-way sync with 30+ booking channels, including Booking.com, Airbnb and Expedia: inbound reservations, outbound availability and rates.
Rate and restriction management — set once, distributed everywhere, with per-channel adjustments where a marketplace demands them.
A unified guest inbox, pulling conversations from every channel into one thread per stay, with AI-drafted replies, translation for guests writing in another language, and automatic filtering of the courtesy messages that need no answer at all.
Payments and deposits through Stripe and Paymentsense, handled inside PCI DSS scope so the property never touches card data.
Reporting on occupancy, rate and channel mix — from the same ledger the calendar reads, so the numbers cannot disagree with the front desk.
Web and mobile, because the person who needs to check tomorrow's arrivals is often not sitting at the desk.
The stack is Next.js and TypeScript on the front, NestJS over Postgres behind it, Flutter for mobile, and AWS underneath. Nothing on that list is fashionable. All of it is boring on purpose — the property is going to run on this for years, and somebody who is not us will maintain it eventually.
The hard part was not the features
It was that every channel lies to you, and none of them lie in the same way.
Not maliciously. But a marketplace webhook arrives late, or twice, or out of order. A cancellation can land before the booking it cancels. An availability push returns a 200 and then quietly does nothing. A rate update is accepted and applied nine minutes later. Retry the request and you may have just created a second reservation — or you may have created nothing, and you have no way to tell from the response.
So the sync layer is written on the assumption that the channels are unreliable narrators. Inbound messages are idempotent: the same reservation delivered three times produces one booking, because identity comes from the channel's own reference and not from the fact that a request arrived. Ordering is not trusted — a cancellation for a booking we have not seen yet is held rather than dropped, and applied when its subject appears. And a reconciliation sweep re-reads channel state on a schedule and compares it against the ledger, because the only way to know a push actually landed is to go and look.
None of that is visible in a demo. All of it is the difference between a system a hotel trusts with its inventory and one where the manager keeps the spreadsheet open "just in case" — which is the same as not having the system at all.
Where it is now
Stayvieo is live in independent properties, running the parts of the operation that fail loudest when they fail:
30+ channels kept in step from one calendar
Rates and availability distributed automatically rather than re-typed
One inbox in place of four, with drafting and translation on top
In-room dining ordered by QR code and posted straight to the guest's folio, through FoodCiti — the two platforms sharing a guest rather than integrating with each other
That last one is worth a sentence. A guest scans a code in room 12, orders, and the charge appears on their bill without anyone carrying a docket. It only works because both systems were built by people who had to live with the seam.
What it taught us
Three things we have carried into everything since.
Pick the unit before you pick the features. Almost every hard question in Stayvieo — conflicts, reporting, rate parity, overbooking — resolved itself once the room-night was the only thing that existed. The decisions that matter are the ones about what a record is. Get that wrong and no amount of application code rescues it.
Assume every integration is an unreliable narrator. External systems will duplicate, reorder, silently drop and confidently lie. Idempotency, deferred application and a reconciliation sweep are not defensive extras; they are the integration. We now scope them in from the start, because the alternative is discovering them at eleven o'clock on a Saturday.
Trust is the actual product. A property manager who still keeps the spreadsheet has not adopted your system. Everything above — the ordering, the replays, the sweeps — exists to close the gap between "the calendar says the room is free" and "the room is free." That gap is the whole business.
Stayvieo is one of two platforms we build and operate ourselves. Running our own products in production is a deliberate choice: it means we live with our architectural decisions on a bank holiday weekend, the same way our clients do.
We build systems businesses actually run on — and we run two of our own. If your availability lives in four places and you are hoping they agree, tell us about it.
