Travel platforms, built around inventory that expires every single night.

Inventory, rate and availability modelling

What exactly is being sold, and in what unit. A hotel sells room-nights by room type against an allocation. A short-term rental sells a whole property with minimum stays, changeover days and a calendar the host also edits from their phone. A charter sells a vessel with a skipper who is a separate constraint. These are not the same object with different labels.

Rates are a second dimension that teams routinely collapse into the first. The same room-night has a different price by length of stay, by how far ahead it was booked, by cancellation flexibility and by channel. A platform that stores one price per night per room will be rebuilt the first time revenue management asks a real question.

The output is an inventory and rate model that can express your commercial policy without a code change.

The booking engine and the hold

A booking is not a write, it is a reservation of scarce capacity that must survive concurrency. Two guests reaching checkout for the last room at the same moment is not a rare race, it is Tuesday during a conference. The answer is a hold with an expiry taken before payment is attempted, released deterministically if payment fails.

The lifecycle after confirmation is where most platforms are thin. Modifications that change dates or occupancy have to re-check availability and re-price. Cancellations have to apply the policy that was in force at booking time rather than the current one. No-shows need their own state, because they are not cancellations and the money is treated differently.

Every one of these transitions has to be idempotent, because confirmation emails, webhooks and channel updates all get retried.

Channel distribution and the double-booking problem

The moment your inventory is sold anywhere other than your own site, availability becomes a distributed consistency problem. A property listed on your platform and on two other marketplaces has three systems believing they can sell tonight, and none of them is authoritative unless you make one so.

There are two honest architectures. Either you hold the master calendar and every channel reads from you, or you accept an external master and reconcile continuously with a defined lag. What does not work is treating each channel as equal and hoping updates arrive fast enough, which is how a host ends up cancelling on a guest and losing their ranking on every platform at once.

Whichever you choose, the platform needs to detect a conflict rather than discover it from a complaint.

Payments, deposits and host payouts

Travel money moves on a timeline unlike any other sector. A guest pays weeks or months before they arrive, so the platform is holding funds it has not earned. A deposit may be authorized rather than captured. The host is paid after check-in rather than at booking, which means your ledger carries a liability with a date attached.

Cancellation policy is where this gets sharp. A flexible booking cancelled inside the window refunds fully; a non-refundable one does not; a partial refund splits differently between platform fee and host share depending on your terms. All of that has to be computable from records rather than decided by a support agent.

Multi-currency compounds it, because the rate at booking and the rate at payout are different numbers and somebody absorbs the difference.

Trust, identity and disputes

In a marketplace where a stranger is handed keys to a property or a vessel, identity is a safety control rather than a signup field. Verification depth is a commercial decision: ask for too much and supply or demand walks away, ask for too little and you inherit the incidents.

Damage and dispute handling deserves designing before launch, not after the first claim. Evidence has to be captured at the right moments - condition at check-in, condition at check-out, messages between the parties - because reconstructing it afterwards is how a dispute becomes a chargeback you lose.

Reviews are part of this system rather than a separate feature, since they are the mechanism that prices trust across the marketplace.

Seasonality, pricing and peak

Travel demand is not smooth and never has been. Search traffic concentrates around a small number of dates, and those dates differ by destination. Sizing against annual averages is how a platform falls over on the morning a holiday period opens for booking.

Dynamic pricing belongs here too. Pricing that responds to demand, lead time and occupancy is revenue management and we build it as a rules engine your commercial team owns. Personalized pricing by individual user is also buildable, and we will walk you through where it helps and where it attracts attention before you commit to it.

Launch and day two

Supply first, always. A travel marketplace with no properties is not a marketplace, and demand spend against thin inventory converts badly and teaches you nothing. One destination, a real supply cohort, then widen.

Day two here means the first full booking cycle: reservations made, stays completed, payouts run and the first disputes resolved. That cycle takes weeks rather than days, which is why the support window matters. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates.