Time first.Film later.

In summer 2026 the cinema’s website showed its schedule through an aggregator widget. It took up to ten seconds to load, and until then the schedule was a blank space. The ad budget is small, so every visitor who reached the schedule and left was expensive.

Speeding up someone else’s widget made little sense: lazy loading and caching were half-measures. The bot offered “today” and “tomorrow” buttons, but people need to pick a date and time straight away. So the decision was to build our own booking.

The key question was where free times come from. The cinema’s calendar became the source of truth, with our own booking service on top. Every booking immediately creates a calendar event and a CRM deal. A 1,000-rouble prepayment holds the time for 30 minutes, and unpaid holds are released automatically.

At Horror Cinema you can’t just show a free hour in a calendar. One film runs about 80 minutes, another almost three hours. The group chooses a fear level and one or two actors. Both the time and the price depend on that.

So the old form demanded every decision before payment. Groups got stuck there: “which film?”, “who’s coming?”, “let’s decide tonight”. Nobody held the time. Prepayments were transfers by card number, then a receipt upload that a manager checked before confirming.

The funnel analysis turned up worse. The site sometimes showed a slot as free when it was already taken. And the on-screen price could differ from the CRM price: the last-minute discount got lost on the way to the server.

The new path is shorter: date, time, rough group size, one or two actors, contact and prepayment. The film and mode are chosen after payment on the “My booking” page.

That was the main engineering problem. With no film chosen yet, how long do you hold the room? A booking takes a standard 120 minutes straight away. A short film doesn’t shrink that window. A long film extends it only after a fresh calendar check, so it never runs into the next session.

Every change on “My booking” is checked and repriced by the server first. If guests open the page in two tabs and change different things, the second tab can’t overwrite the first: the server says the booking has changed and shows the current version. If the rate changes, the new price appears before saving.

The biggest effect came from reordering the steps: once the film moved after payment, twice as many people started a booking. Online booking became the cinema’s main channel: more than half of deals now go through without messaging a manager. Part of the growth is people who used to write in messengers and now book themselves.

The slowest part of booking is agreeing when everyone is free. That used to happen in a chat we couldn’t see. Now the organiser sends one link to the group chat. Everyone ticks the options that suit them, and the page shows real free sessions that work for most people.

Voting doesn’t hold a slot. The chosen session is checked again before booking. Votes are stored without names: the browser gets a random identifier, and only its hash stays in the database.

Payment is where a mistake costs money and trust. So the amount comes only from the booking stored on the server. A browser, bot or link can’t change it.

The payment provider sometimes answers slowly, and a server can restart at the worst moment. So the YooKassa request and its key are saved before sending. After a restart the system repeats the same request, and YooKassa doesn’t create a second payment. The system doesn’t take a payment notification on trust either: it re-reads the payment and checks the amount, currency and booking.