HOURLINE: a concept booking platform with a client side and a studio back office

VITON¹³ builds concept products to show how it approaches software for a business, not only websites. HOURLINE is the booking platform in that series: online booking for premium studios and clinics, shown through Maison Hourline, a fictional house of three studios in Moscow, Dubai and London with nine specialists who do massage, facials, hair, nails and physio. The business, its people, its clients and its prices are invented, and the demo says so on every screen.

The brief we set ourselves had three parts. A guest should book on a phone in seconds, without calling. The times on offer had to be real, computed from the specialists’ hours, breaks, existing bookings and turnover time in each studio’s own time zone, not a decorative grid. And the studio had to see a booking the moment it was made and have tools to protect its day: a calendar it can rearrange by hand, a warning when a visit is likely to be missed and a way to fill empty time.

The guest side is two views, Book and My bookings, designed for a phone first. Booking runs from studio to service, specialist, a date strip with a time grid, name and phone, and a confirmation, with a stopwatch in the card. Each studio shows its local time and whether it is open now. Suggestion chips offer the earliest time, the guest’s usual time learned from past visits and a time with their usual specialist; “book with a friend” finds two specialists free at the same start. The confirmation is a wallet-style pass with a calendar file (.ics) generated in the browser. In My bookings a visit can be moved by dragging it along the specialist’s day, where it snaps to free starts, or cancelled under the studio’s policy, with its free window and late fee.

The studio side is five views. The calendar shows a day with a column per specialist, grouped by studio, each on its own local time with its own “now” line, and a week view. Visits can be dragged to another time or specialist, stretched by the lower edge or created with a click; every change goes through the same rules as the guest side, and a drop that breaks one shakes back with the reason, such as an overlap with another booking. The dashboard shows revenue, a utilisation heatmap by weekday and hour, new and returning clients, cancellations, no-shows and lead time; Clients holds tags, lifetime value, history and notes; Settings changes services, prices, hours, breaks, buffers and the cancellation and deposit policy, and the booking page follows at once.

The fifth view, Intelligence, is what we call demo AI and label as such on the page: rules plus statistics, computed in the browser. Each upcoming visit gets a no-show risk from a naive Bayes model trained on the demo’s own history (first visit, lead time, previous no-shows, time of day, weekday), adjusted by rules for a confirmed reminder or a paid deposit; every score lists its factors and suggests an action, such as asking for a deposit. “Fill the gaps” finds free time today and tomorrow and matches it with people on a simulated waitlist; an accepted offer books the slot.

The demo is plain JavaScript and CSS without a framework, bundled with esbuild into a static folder with relative URLs, so it runs from any path: on the portfolio it lives at /demos/hourline/. The guest side loads first and the studio side arrives as its own chunk. One store holds the data for both sides and saves it in localStorage, so a booking made on the guest side is in the studio calendar at once, and in any other open tab through the browser’s storage event. The data is generated for each visitor: a client base for every studio, eight weeks of history and four weeks ahead, built through the same availability rules as the product, so the calendar opens full and consistent.

One availability engine answers every question the product asks: can this specialist take this service at this minute on this day, given their weekly hours and break, live bookings, the buffer after each appointment, the minimum lead time and the booking horizon, in the studio’s time zone. The guest’s slots, the suggestions, the friend pairs, rescheduling, the studio’s drag and drop and the gap finder all ask it. The design is a cream-and-stone palette with an aubergine accent, Cormorant for display and Manrope for text, both self-hosted; springs and the intro turn into instant changes for visitors who ask for reduced motion. The whole interface is in English and Russian.

What exists now is a working concept at tarasovvitalii.com/demos/hourline/ with seven views, two for the guest and five for the studio. On 28 September 2026 we measured it in headless Chrome on a MacBook, with the demo clock frozen at 1 October, 15:40: a scripted booking on a 390 px phone screen, pausing 0.9 seconds after every tap, took 6 seconds from the first tap to the confirmation on the demo’s own stopwatch (median of 14 runs, 6 to 16 seconds). A booking made in one tab appeared in a studio calendar open in another, and a price changed in Settings reached the booking page.

An independent brute-force check inside the page re-tested all 658 times the engine offered over ten days in three studios and nine services against hours, breaks, bookings with their buffers, lead time and the time-zone round trip: no wrong slot, no double booking and no buffer violation; the same check with the clock moved across London’s change to winter time on 25 October found nothing either. All the JavaScript and CSS weigh 95 KB gzipped. On the live address, Lighthouse 13.5 (five runs per device, medians, on a MacBook with a load average of 3–9) gave performance 94 on mobile and 100 on desktop, with accessibility and best practices at 100; the page transfers 0.2 MB on load.

HOURLINE is a concept VITON¹³ built to show range, not a commissioned project. Maison Hourline, its studios, specialists, clients, prices and bookings are fictional and generated in the visitor’s browser: there is no client, no users, no real bookings, no traffic and no revenue, and nothing in the demo is for sale. Reminders, deposit requests, waitlist offers and their replies are simulated; no message, payment or personal data leaves the browser.

The demo AI is rules and statistics in the browser, not a language model, and it learns from invented history, so it proves nothing about predicting real no-shows. The 6 seconds come from a script tapping at a fixed pace, not from people, and no user testing was done. Every figure is a lab measurement in headless Chrome on one machine on one day, and Lighthouse ran on the live address with a simulated phone, not on real devices. A production version would still need a server with slot locking, payments, real reminders, accounts and data protection.

How to check a web studio’s portfolio →