DEV Community: Kayabyte

Room types, not rooms: how a small B&B booking engine avoids double bookings

Kayabyte — Thu, 22 Oct 2026 08:06:31 +0000

Full disclosure up front: I build Wix apps, and Stay Direct, the booking app this post is based on, is mine. The booking logic below works the same on any platform.

The difference between a cabin and a B&B

A holiday cabin is one unit: it is either free on a night or it isn't. A small B&B or guesthouse sells room types instead: "Double room with garden view, 4 rooms". Guests don't pick room 3, they pick the type, and the owner wants the calendar to keep selling until every room of that type is taken.

That sounds like a simple counter, but one rule makes it harder: a guest keeps the same room for the whole stay. Nobody wants to move rooms on night three.

What you can use before building anything

If you are on Wix, check the built-in routes first. Wix Hotels by HotelRunner is Wix's own hotel app; it handles room types and comes with a channel manager, which suits a hotel that already works that way. Wix Bookings is made for appointments and classes, so nightly stays across several rooms don't map onto it well. And plenty of small places simply link a "Book now" button to their Airbnb or Booking.com page, which costs nothing but keeps paying the commission.

What follows is for the case in between: a few rooms, direct bookings on your own site, and calendars that stay in sync with the big platforms.

Free rooms, not free nights

So the check is not "is there one free room each night" but "is there one room that is free on every night of the stay":

// blocks: bookings, holds and imported calendar blocks; unit = room number, or none for "all rooms"
function freeRooms(checkIn, checkOut, blocks, rooms) {
  const overlapping = blocks.filter((b) => b.start < checkOut && checkIn < b.end);
  const free = [];
  for (let room = 1; room <= rooms; room++) {
    const taken = overlapping.some((b) => b.unit == null || b.unit === room);
    if (!taken) free.push(room);
  }
  return free;
}

A request for two rooms needs two entries in that list. And there is a third answer besides yes and no: every night has a free room, but never the same one for the whole stay. Telling the guest exactly that ("try different dates or two shorter stays") is better than a plain "unavailable".

Calendars per room

Most small places also list on Airbnb or Booking.com, which sync through iCal links. With room types, each physical room needs its own export link and its own imported calendars, because Booking.com may sell room 2 while Airbnb sells room 4. An imported block takes one room; a block the owner adds by hand ("closed for painting") can take all of them.

Rate options

B&Bs rarely have one price. The usual set is a standard rate, a cheaper non-refundable rate and a rate with breakfast. Modelling them as options on top of the nightly price keeps it simple: a percentage up or down per night, an optional amount per guest per night (breakfast), and its own deposit rule (a non-refundable rate is often paid in full at booking).

Keeping old bookings safe

The tricky part of adding rooms to an existing booking engine is the data that was there before. Old bookings have no room number. The safe default is "room 1": for a property with one room nothing changes, and when an owner later raises the room count, old bookings keep occupying exactly one room.

Summary

For multi-room properties: book room types, assign a concrete room for the whole stay, explain the "same room" case clearly, keep one calendar link per room, and treat old bookings as room 1.

If you run a B&B, guesthouse or holiday rental on Wix, Stay Direct does this on your own site, with iCal sync to Airbnb, Booking.com and Vrbo and deposits through your checkout, and a free plan for one property (online payments need a Wix Premium plan and a connected payment provider). It only works on Wix sites, and it syncs booked dates, not prices.

Stay Direct on the App Market: https://www.wix.com/app-market/6de5633d-3a41-473c-a642-20b4ba638d1d

Booking for kennels and dog daycares is a capacity problem, not a calendar problem

Kayabyte — Thu, 22 Oct 2026 05:32:31 +0000

Full disclosure up front: I build Wix apps, and the one this post is about, Pet Boarding, is mine. Most of this post is about the booking logic itself, which applies whatever platform you build on.

Why appointment tools don't fit

Most booking tools are built around appointments: one client, one staff member, one time slot. A kennel or a dog daycare works differently:

A boarding stay is a range of nights, from a drop-off day to a pick-up day.
Daycare is a set of single days, sometimes half days.
What runs out is space, not staff time. A kennel with 12 runs can take 12 dogs per night, whoever books them.
Price depends on the pet, not just the service: size tiers, a discount for a second dog from the same family, weekend or holiday extras, a late pick-up fee.

So the core question for every request is "is there a free space on every night of this stay", and the price is a sum over nights and pets.

Capacity per night

The availability check counts how many spaces are taken on each night of the requested stay and compares that with the service's capacity:

// taken[night] = spaces used that night by confirmed bookings and live holds
function fits(stayNights, petsNeeded, capacity, taken) {
  return stayNights.every((night) => (taken[night] ?? 0) + petsNeeded <= capacity);
}

Two details matter in practice:

Family suites. Many kennels put dogs from one family in one run. With suites on, a family of two dogs uses one space, so petsNeeded becomes the number of suites, not the number of pets.
The calendar should only offer dates that work. The widget asks the backend for free spaces per night in the visible months and greys out days where the stay could not start, so owners don't pick dates and then get an error.

Holds, because payment takes time

Between "Continue" and a finished payment, two owners can try to take the last space. A short hold solves that: when a checkout starts, the space is held for the stay's nights, and the hold expires if nobody pays. Capacity is checked again when the hold is written, and simultaneous requests for the last space get a clear winner, so two owners can't both take it.

Manual payments (cash or bank transfer at drop-off) need a longer hold, because the order exists but the money comes later. In the app, online checkouts hold the space for 30 minutes and pending manual payments for 3 days.

Prices per pet

The quote is built night by night and pet by pet, then adjusted:

base price per night (boarding) or per day (daycare, with a half-day price),
a size tier per pet,
an extra-pet discount for the second and later pets of the same owner,
weekend and peak-date extras,
a long-stay discount above a number of nights,
a late pick-up fee when the pick-up time is after the cut-off.

Rounding happens in the currency's smallest step, so a 10% discount on a price in yen or Indonesian rupiah doesn't produce fractions.

Records that have to stay private

Owners upload vaccination records (PDF or a photo). These are health-related documents about someone's pet and contact details about the owner, so they are stored per site, served only to that site's dashboard, and size-capped (5 MB per file). Old owner and pet details are cleared after a retention period.

What the business sees

The part kennel owners care about most is not the booking form but the day: who is dropping off today, who is picking up, which pets are in care and any care notes. A printable day sheet, an occupancy calendar and a form for bookings taken by phone matter more to them than any widget design.

Summary

If you build booking for boarding or daycare, model capacity per night (or per day), make holds part of the capacity check, price per pet, and treat uploaded records as private data from the start.

If you run a kennel, cattery or dog daycare on Wix, Pet Boarding does this on your own site, with deposits through your checkout and a free plan for one service. It only works on Wix sites. More about it: https://kayabyte.dev/wix/pet-boarding/

Wix Events has no total ticket limit per event. Here's what works, and how I built one

Kayabyte — Wed, 21 Oct 2026 23:14:26 +0000

Full disclosure up front: I build Wix apps, and one of them, Event Capacity & Waitlist, does what this post is about. I'll cover the built-in options first, because for many events they are enough, and then the technical side of how a shared limit can be built on top of the Wix Events APIs.

The problem

Wix Events sets ticket limits per ticket type, not per event. Wix says it directly in a feature request: "You cannot set a general ticket limit of how many tickets you can sell per event."

A typical case: a room for 40 people, with "Standard" and "VIP" tickets. You can't give each type 20, because you don't know the split. You can't give each type 40, because then you might sell 80.

Built-in option 1: one ticket type with price options

If your ticket types only differ in price (adult, child, member), use one ticket type with several price options and set its quantity to the room size. All prices then sell from one pool.

The catch: price options share one name, one description and one sale period. If VIP needs its own description, or early-bird tickets should stop on a date, they have to be separate ticket types again.

Built-in option 2: a seating map

A seating map caps the event at the seats and areas on the map. An "Area" element has a total number of spots, which works for standing room. But each seat or area belongs to one ticket type, so two types can't share the same free places.

Built-in option 3: RSVP events

RSVP events (no payment) have a guest limit and a built-in waitlist. Ticketed events don't: Wix's help article says "Waitlists are not available for ticketed events", and an event can't be switched from ticketed to RSVP later.

Building a shared limit on top of the APIs

Wix has no "event capacity" field to set, so the app works with what exists: each ticket definition's own limit, and the event's tickets-per-order setting. The idea is simple. After every order, recalculate each ticket type's limit:

// remaining = total capacity minus everything sold or held, across all types
const used = types.reduce((sum, t) => sum + t.sold + t.reserved, 0);
const remaining = Math.max(0, capacity - used);

for (const type of types) {
  const taken = type.sold + type.reserved;
  let limit = taken + remaining;                          // what it may sell now
  if (type.ownerLimit !== null) limit = Math.min(limit, type.ownerLimit);
  await setTicketLimit(type, Math.max(limit, taken));     // never below what's sold
}

A few things that turned out to matter:

Remember the owner's own limits. If the owner set VIP to 20, the app must never raise VIP above 20, and it must put 20 back when the shared limit is switched off. The app stores what it wrote, so it can tell its own values apart from limits the owner changed later.
Mixed orders. Per-type limits alone let one order take 4 Standard plus 4 VIP when only 4 places are left. The event's "ticket limit per order" counts across types, so the app keeps it at or below the places left.
Held tickets count. Tickets in an open checkout are reserved, and they need to count as used, or two buyers can check out the same last place.
Concurrent writes. A sale and a recalculation can touch the same ticket definition at once. Updates carry a revision, and a conflict means: read everything again and retry.
Sold-out events get no more order events. If a recalculation is interrupted (for example, the owner leaves the page right after saving), nothing triggers the next one. The settings card now checks on open whether the stored limits match the settings, and finishes the update if not.

There's still a small window between an order and the recalculation, so two checkouts started at exactly the same moment could, in rare cases, go one over.

A waitlist for a ticketed event

When the shared total is used up, the app shows a "Join the waitlist" form on the event page (a site plugin on the event details page). When places free up, because an order is cancelled or the owner raises the total, it fires a Wix Automations trigger, so the site's own email goes to the next people in line. It doesn't send email itself, and it doesn't reserve the ticket: the person buys it the normal way.

Summary

Ticket types that differ only in price: use price options. Free, and one pool.
Fixed seats: a seating map.
No payment needed: an RSVP event with its built-in waitlist.
Different ticket types sharing one total, or a waitlist for a paid event: that needs an app.

If you go the app route, Event Capacity & Waitlist is on the Wix App Market, with a free plan for one event. I wrote a longer, non-technical walkthrough of the built-in options here: https://kayabyte.dev/guides/wix-events-total-ticket-limit-waitlist.html

Questions about the APIs or the approach are welcome in the comments.