02 of 04
Two platforms and a telephone, all able to sell the same weekend.
A house of eight rooms at 1290 metres, at the top of the Giuvala pass, rented whole rather than by the room. It is listed on Airbnb and on Booking.com and it also takes bookings over the phone, which is three calendars that do not know about each other and one weekend between them to sell. The site merges all three into one set of blocked nights and publishes the phone bookings back out as a feed the two platforms subscribe to. An assistant sits on every page and answers in Romanian, and dates are the one thing it is forbidden to answer from memory: it calls the same availability check the booking form calls, and reads back what it is told.
A property listed on Airbnb and on Booking.com has two calendars it does not control. Add the guests who ring up and there is a third, which lives in somebody’s head. Each of the three can sell the same weekend, and the house is rented whole, so there is no spare room to move anybody into when two of them do.
The second problem is quieter. Most of what a guest wants to know is already written on the site, and it still arrives by telephone, at whatever hour it occurs to the guest. Both questions were being answered by hand, and the one about dates cannot be answered wrong.
The public site is twelve pages: the eight rooms one after another, the facilities, the gallery of 75 photographs in three sets, the attractions and the activities around the pass, its history, the page about the owners, the page about renting the house whole, contact, and the two legal pages. A thirteenth route is the admin login. Every heading, paragraph, image and button on those pages is one of 151 editable slots, and each one ships with its original text beside it in the source, so a database that cannot be reached leaves the page complete rather than blank.
The availability endpoint reads the Airbnb feed, the Booking.com feed and the direct bookings in the database, merges them into one set of blocked nights, and remembers which source blocked each one. A feed having a bad afternoon is skipped rather than fatal, because a booking platform being down should not take the website with it. The merged answer is cached for sixty seconds, and every write collapses that window to nothing.
The booking form does not trust the calendar it has just drawn. On submit the server runs eight validations against the rules held in the settings document, minimum and maximum nights, how far ahead a stay may be booked, party size, turnaround between guests, and then refetches both platform feeds uncached, because the only reading that counts is the one taken at the moment of writing. Then it writes the reservation, emails the guest and the owners, and busts the availability cache.
Direct bookings go back out as a calendar feed the two platforms subscribe to, so a weekend sold over the telephone closes on Airbnb and on Booking.com without anyone opening either. One detail from the build is worth keeping. Airbnb rejects a feed with no events in it, so the feed carries a single all-day event on 1 January 2024 titled Calendar sync active. It is emitted unconditionally, and it is the reason the integration survives a quiet month.
A guest asks in Romanian and it answers out of a knowledge base built from the site’s own pages. Dates are the exception. The prompt requires it to call the availability check immediately and to answer exclusively from what comes back, never from memory and never from the page. The check calls the same endpoint the booking form calls. If the check fails, what the assistant is handed is the telephone number rather than a guess.
Six tools sit behind the conversation and the browser is what executes them. It opens a page, scrolls to a section, checks dates against the merge, offers the booking, and opens the booking dialog. So the answer about what the house has arrives with the facilities page already open at the right section, rather than with directions to it.
Signed in, every heading, paragraph, image and button on the public pages becomes editable where it sits, 151 slots across 202 editable components, with undo and redo per field. Saving writes the content document and then regenerates the knowledge the assistant answers from, by plain string concatenation out of the same collection the page reads. There is one copy of the words, and what the assistant knows is rebuilt out of it.
Two allowlisted Google accounts reach the admin bar, and the entire admin tree is a dynamic import that loads only when the visitor looks like one of them, so the public bundle never carries it. Behind the bar sit the reservations, pending, confirmed and cancelled, the availability calendar coloured by source, the nightly rates and stay rules, and an email diagnostics panel. Cancelling a booking leaves the row and reopens the nights; only an already cancelled booking can be deleted.
A weekend sold on the telephone is typed in once. It shows up as three green nights in the owners’ calendar, as a card on the confirmed tab, and as the reason the assistant tells the next guest those nights are gone. It leaves by the outbound feed at the same time and closes the same weekend on both platforms. One write, four surfaces, and no second copy of the truth to fall out of step.
The scheduled sync was deleted sixteen minutes after it was written, because the plan that runs it costs money. What replaced it refreshes the calendar on demand, at most sixty seconds stale, thirty times fresher than the schedule would ever have been.
The timestamp helper already ended in a Z. The first version of the outbound feed stripped the milliseconds off it and then appended a second one, and that one-line typo invalidated the entire outbound integration, which is the half of the system that stops a weekend sold on the telephone being sold again on Airbnb. Nothing threw. The only symptom was Airbnb declining to subscribe. The commit that fixed it, on 2 April, takes out a single call.
Reservation emails failed silently in production for months, and two faults were stacked. A non-2xx from the mail provider is a perfectly successful fetch, so every rejection for an unverified sending domain read as a send. And the promise doing the sending was floating, so the serverless invocation was killed the moment the response went out and the call never settled, which lost even the error. One afternoon in August repaired both and added a panel that puts a failure on screen instead of leaving it in the logs.
Every call is priced from its own token usage against a ceiling of ten dollars a day. The ceiling is real and it is softer than it looks: the counter it reads is a variable inside the serverless instance, so a cold start puts it back to zero, and the authoritative total written to the database is read by nothing and displayed nowhere. A one-token health check confirms the key still works, and when it does not, the chat bar is not rendered at all. A guest never meets a chat that is broken.
In April a commit fixed a timezone fault that had been shifting every blocked date a day late in the two calendars where it had been seen: dates built in local time and then formatted as UTC. The same mixture is still in the server’s turnaround loop, where it drops a day on 28 and 29 March in Romanian time. It is latent, because the turnaround buffer defaults to zero. There is no test in this repository that could have found the third place.
Live, and a client’s business, in Romanian throughout. Four things are honestly unfinished. There are no tests at all, no runner and no test file, so every rule in the booking flow is upheld by reading the code. The linter reports two errors and thirty-one warnings. The booking dialog still carries per-source colours it can never draw, for the reason given under the calendar above. And the route the deleted cron used to call is still there, still commenting that a schedule calls it every thirty minutes, called by nothing.
