An operator running charters on Freebo pinged me yesterday. They had a booking come through on one of the big vertical marketplaces — the kind of site where a customer types “half-day charter” plus a city name and clicks around ten operators before picking one. The booking landed on that marketplace’s calendar, not on Freebo’s calendar. The next request they had for me was, verbatim:
Can you drop a $0 placeholder booking on Freebo for Thursday afternoon so nobody double-books it? Don’t send any notifications.
That single sentence is a category of missing feature. I want to unpack why.
What actually gets blocked
The operator has one boat. It can be booked from at least three places: their own Freebo booking page (where their marketing sends people), the marketplace they get lead flow from, and the phone — an actual human calling to ask if Thursday afternoon is open.
Every one of those channels has to look at the same underlying scarce resource. One boat. One captain. One four-hour block on Thursday afternoon.
Freebo is the source of truth for the operator’s calendar. When they take a phone booking, we know about it. When their own site takes a booking, we know about it. When the marketplace takes a booking, we do not know about it — until the operator opens a laptop and manually stubs one out in Freebo to prevent our availability engine from happily selling the same slot to a second customer.
The $0-with-no-notifications construct is exactly what a stub reservation looks like. Zero dollars because no money moved through Freebo. No notifications because the customer already got their confirmation from the marketplace and would be confused as hell to receive a second one from a booking system they’ve never heard of. It just needs to exist as a row in the database that our availability engine will respect.
The dance, from the code’s perspective
The knobs to do this by hand already exist in the reservation routes because they’re generally useful for other cases — offline bookings, group holds, comped reservations, whatever. So the manual process works. It’s ugly, but it works.
The send_notification: false flag is a first-class parameter on the reservation flow. It suppresses the customer-facing confirmation email but still lets the staff-facing side of the system record the state correctly. It’s used in cancellation and rebooking paths too — anywhere the operator needs a state change without spamming the customer.
The placeholder: true flag rides along in the reservation’s previous_inputs metadata blob. That’s less clean than I’d like — it’s essentially a note-to-self stored on the reservation so downstream code can tell “this was a manual block, don’t treat it like a real transaction.” Analytics ignore it. Payment reconciliation ignores it. The availability engine treats it the same as any other reservation, which is the whole point.
Why the manual process is the actual bug
The knobs work. That’s not the problem. The problem is that the operator has to log into a laptop, remember to check both boxes, remember to enter $0 instead of the actual amount that landed in their marketplace account, and remember to double-check the timezone. Every time. Forever.
Every one of these operators does this. The ones on the popular vertical marketplaces. The ones taking Viator listings. The ones showing up on Airbnb Experiences. The ones running an old Wix widget on a landing page for tourists arriving from a specific hotel chain. It’s not a Freebo problem — it’s a booking software problem. And every booking platform I’ve ever looked at either ignores it, charges extra for it, or half-solves it with a fragile hand-rolled integration for the biggest three OTAs and nothing else.
What the actual fix looks like
The lazy answer is “just build a webhook integration with the marketplace.” Except most of these marketplaces do not offer webhooks. And the ones that do gate them behind partnership programs that require volume commitments a small operator will never hit.
The pragmatic answer is the iCal feed. Every serious calendar system on earth speaks iCal. Airbnb, Booking.com, Vrbo, most of the vertical fishing/tour marketplaces — they all publish a per-listing iCal URL that any other calendar can subscribe to. That URL updates whenever a booking is made or canceled on that platform.
The plan I’ve been sketching for the last week:
- DiscoveryOperator adds an iCal URL to their Freebo productOne-line paste on the product settings page. We validate it's a well-formed iCal feed and we can reach it.
- IngestionA worker polls the feed every 5 minutes per operatoriCal has no push. Polling is the API. Every event in the feed becomes a candidate placeholder reservation.
- ReconciliationDiff the new feed against last pollNew event → create a placeholder reservation with send_notification: false. Removed event → cancel the corresponding placeholder. Timezone changes → update. Nothing about the operator's real bookings gets touched.
- GuardrailsAvailability engine sees placeholders as blocksThe engine already treats every reservation as a block. Placeholders inherit that behavior automatically. What the engine cannot do — yet — is refuse to write a new reservation because we're mid-poll and the placeholder is 90 seconds late.
- Race windowThe five-minute race is the actual hard problemBetween polls, the marketplace can accept a booking that Freebo has already accepted for the same slot. The only real fix is treating the OTA as the authoritative source for its own bookings and never letting Freebo's own booking page double-sell without a re-check.
The race window is where 90% of the actual engineering work lives. Everything else is plumbing. The interesting question — the one I’ll be chewing on for a week — is how much of a race window is acceptable, and whether we should hedge by re-polling the feed the moment a real Freebo booking lands for a slot on the same product.
The generalization
Any business software that manages a scarce resource ends up in this shape the moment a second channel starts touching that resource. Restaurant reservation systems have it with OpenTable and Resy. Salon booking systems have it with Fresha and Vagaro. Hotel PMSes have it with every OTA on Earth and a whole vocabulary — “channel manager” — for the middleware that solves it.
The manual $0 placeholder is the tell. Every time an operator does that, it’s a booking platform admitting it doesn’t know about a channel it needs to know about.
— the one-liner
You don’t need to invent the fix. Hotels already ran this play. The fix is that the underlying platform stops pretending it’s the only calendar and becomes fluent in listening to everybody else’s. iCal is the lingua franca. Webhooks where available. Polling as the fallback. And a very careful conversation with the availability engine about what happens in the 300-second gap where two customers on two different websites can both hit “book” for the same afternoon.
Getting that gap down to zero is the actual product. The $0 placeholder is what “the gap is currently five hours because a human has to log into a laptop” looks like when a customer describes it in a chat message.