Public self-service booking, availability computed from your own rules, and capacity enforced inside the database rather than hoped for in the application.
RingUps books bridal appointments. A bride books herself on the store's own public booking page, or a staff member books her at the counter, and both land in the same appointment book. Availability is computed from the store's rules at the moment she asks. Capacity is enforced inside the database, so the same slot cannot be handed to two brides.
A generic scheduler books a person for a length of time. That is not what a bridal store is selling. Five things sit inside a bridal appointment, and every one of them changes what the store can honestly offer.
It computes them at the moment she asks. RingUps does not create rows of empty appointments in advance and then hand them out. There is no calendar to generate, no month to open up, and no stale slot left behind when you change your mind about Saturdays.
That distinction sounds academic until you shorten your Saturday. In a system built on pre-generated slots, the empty rows already exist and someone has to go and delete them. In RingUps the rule changes and every future Saturday changes with it, including the one a bride is looking at on her phone right now.
| Input | Where it comes from | What it does to the times she sees |
|---|---|---|
| Hours for the appointment type | The booking rules you write, per type, per weekday | A first appointment can open at 09:30 on a Saturday and not run at all on a Tuesday |
| Duration of the type | The appointment type itself | A first appointment and a second appointment reserve different amounts of the day |
| Capacity for that day | How much the store can actually run at once | Once the day is full, no further slot is offered, whoever is asking |
| Date-specific closures | Dates you close | A buying trip removes the whole week without touching the weekly rules |
| Statutory holidays | A holiday table of 20 rows, Canada-wide plus British Columbia, covering 2026 and 2027 | Those dates return nothing, without anyone remembering to block them |
| Appointments already booked | The appointment book itself | Every confirmed booking reduces what the next visitor is offered, in the same request |
Two brides, two phones, the same 10:00 on the same Saturday, half a second apart. This is the failure a store actually fears, because nobody finds out on the day it happens. Somebody finds out three weeks later, standing in the doorway with four guests, being told there has been a mistake.
Most booking software checks and then writes. It asks whether 10:00 is free, is told yes, and then inserts the row. Those are two separate trips, and there is a gap between them. If a second request arrives inside that gap, it is also told yes, and now two people hold the same room.
One function inside the database does the counting and the writing. There is no version of this that runs in the browser or in a server the store does not control, so there is no second path that could skip the check.
An advisory lock, held per day. While one booking for Saturday is being decided, a second booking for Saturday waits. Sunday is untouched, so a busy store is not serialised behind one queue.
It waits milliseconds, then counts again against the booking that was just made, finds no room left, and is declined on the spot. The refusal happens in the same place the row would have been written, so there is no window between the two.
The same guarantee holds whether both requests came from two brides on the public booking page, or from a bride online and a staff member on the phone at the same moment.
This is the part most scheduling tools cannot say. Capacity that is enforced in application code is enforced only as long as there is one copy of that code running and nobody ever books from anywhere else. Capacity that is enforced by the database is enforced for every path into it, permanently, including the ones nobody has written yet.
Seven steps. What the store does is on the left of each one, what RingUps does is on the right. This sequence has run end to end in production against Cande Bridal Boutique's real booking page.
The store gets a public booking page of its own. It goes in the Instagram profile, the Google listing and the bottom of every email. Nothing behind it needs a login.
A first appointment and a second appointment are different types with different lengths. The type she picks is what the next step is computed against, so she is never offered a ninety-minute slot for a twenty-minute visit.
Hours for that type on that weekday, minus closures, minus statutory holidays, minus what is already booked against the day's capacity. In the production run the page returned 12 open slots, computed for that request rather than looked up.
Name, email, the date of the wedding, how many people she is bringing. Party size arrives with the booking rather than as a surprise on the day.
It takes the advisory lock on that day, counts what is booked, and either writes the appointment or refuses it. If two requests arrive together, exactly one of them wins, and the other is told immediately rather than three weeks later.
Through the same email pipeline that has delivered 100 messages in production with real Resend message ids. Every send is logged on her record, and so is every message the system held back, with the reason in plain English.
On the day view, with the room, the consultant, the type and the party size, next to everything the counter booked by hand. There is one book, not a staff calendar and a website calendar that have to be reconciled on a Friday night.
One day view. Booked online and booked at the counter sit in the same list, because they are the same kind of record.
Public self-service booking is not a screen we have designed. It ran end to end in production. The booking page returned 12 open slots, a booking was confirmed, and the row it created was checked in the database afterwards. That is the whole claim, and it is the whole evidence for it.
The migration figure is a migration figure. Cande Bridal Boutique has been trading since, so the live total is higher, and RingUps does not present one as the other.
| What runs it today | What goes wrong | What RingUps does instead |
|---|---|---|
| The paper book at the front desk | One person can read it, in one building, one page at a time. Nobody at home on a Sunday can answer a bride. | The book is a database. The floor, the workroom and the owner read the same day view. |
| A general online scheduler bolted on the side | It books a person for a length of time. It does not know about a fitting room, a party of six, or a first appointment that runs ninety minutes. | Appointment types carry their own duration and count against the store's own capacity, room and consultant included. |
| The direct-message inbox | She asks at 11pm. Somebody answers at 10am. By then she has booked with the store that let her book at 11pm. | She books herself, and every time she is offered is a time the store can genuinely take. |
| The person who keeps Saturday in their head | The rules are real but unwritten, so they leave with the person on the day they are off sick. | The rules are written once and applied identically to every request, whoever is on the floor. |
Most independent boutiques take bookings three ways at once: the paper book at the desk, direct messages on Instagram, and whatever their store system offers. BridalLive and Bridal Web Solutions both keep a scheduler, and both are perfectly capable of holding an appointment. The risk is rarely the scheduler itself. It is that the store is booking from more than one place and reconciling them by memory.
The safe shape is one book with one gate in front of it. Every path into the diary, whether that is a bride on her phone at 11pm or a consultant on the phone at the counter, goes through the same function, and that function is the only thing allowed to write an appointment. If the check and the write happen in one place inside the database, holding a lock on the day, the race that produces two brides in one room stops being possible rather than becoming unlikely.
That is how RingUps is built, and it is how Cande Bridal Boutique in Kelowna, British Columbia runs its Saturdays. It is worth asking any system you are considering the plain version of the question: if two people click the same slot in the same second, which one gets it, and what stops the other.
The booking creates or matches a bride. Go here to see what a consultant is looking at when she walks in, and what history the appointment is attached to.
Confirmations and reminders come from here. Go here for what the templates look like, and for why a message was held back with the reason written in plain English.
Fittings live here rather than on the appointment calendar. Go here to understand the split before you decide how your workroom books its own time.
Yes. Public self-service booking ran end to end in production on Cande Bridal Boutique's booking page. The page returned 12 open slots, a booking was confirmed, and the resulting row was verified in the database. A bride chooses an appointment type, sees times computed from the store's own rules, and receives an email confirmation.
No. The booking is created by a function inside the database, and that function takes a lock on the day before it counts anything. Two requests arriving in the same second are handled one after the other. The second one recounts, finds no room left, and is refused, so there is no gap between checking and writing for a double booking to slip through.
It computes them when she asks, rather than storing pre-generated empty slots. RingUps takes the hours for that appointment type on that weekday, removes closures and statutory holidays, subtracts what is already booked against the day's capacity, and returns what is left. Change your Saturday hours and every future Saturday changes with them.
We will rebuild that day in RingUps on a call, write your booking rules in front of you, and try to book the same slot twice while you watch.