Online booking for a long-standing barbershop
Website, no-signup booking and a floor management system in one application, replacing a twenty-year-old setup.
- Client
- Priolo the Barbers
- Sector
- Barbershop · Palermo, since 1982
- Services
- Web & App Development · Brand & UI/UX Design · GDPR & Privacy
Priolo the Barbers is a Palermo barbershop running since 1982. It had been taking online bookings for years, on a system built with technology long out of support, serving customers from teenagers to eighty-year-olds.
The previous system was built on technology that is no longer maintained.
Many customers have the old page addresses saved in their bookmarks.
Forcing a signup just to book a haircut drives away exactly the regulars.
Two people picking the same slot at the same moment must not both get it.
Someone without a preferred barber shouldn't have to pick one just to book.
Every choice has a constraint behind it
The constraint
The interface responds instantly, before the server confirms. But two customers can pick the same slot at the same instant.
The choice
Overlap is forbidden by the database itself, not by a check in the code.
Why
An application-level check always has a window between verifying and writing where another booking can slip in. By delegating the rule to the database, the second booking is rejected regardless: the interface can stay instant without correctness depending on luck.
The constraint
An account enables history and reminders, but signup is where people drop off.
The choice
You book with a name and a phone number. The account is offered after confirmation, never before.
Why
A customer who just wants a haircut shouldn't pay the price of a feature that serves us. Whoever wants history opts in afterwards, and is reconnected to their past bookings through their phone number.
The constraint
The old page addresses have been in many customers' bookmarks for years.
The choice
Every old address permanently redirects to its matching new page.
Why
A customer who opens a bookmark and finds an error page doesn't go looking for the new site: they call, or they go elsewhere. Keeping those paths costs a few lines; losing them is paid for in customers.
The constraint
A significant share of the clientele is elderly, and a consent banner is a confusing obstacle.
The choice
No tool that requires consent: a map with no tracking, and the phone number remembered only behind an explicit opt-in.
Why
You don't remove the banner by choosing not to show it: you remove it by not using what makes it mandatory. Dropping the tracking cost less than a customer freezing at the popup and closing the page.
The constraint
The client's brief was explicit: the site must be «heavily optimised».
The choice
Measured first, optimised second. The time was going into database queries, not into rendering pages.
Why
Prerendering more pages was the obvious route and would have changed nothing: the admin shell was already instant. Only what measurably paid off was kept, and a prefetch that seemed sensible but made things slower in a head-to-head was removed.
Booking in three steps
Service, day and time, name and phone. You pick the barber, or the shop picks for you.
Floor agenda
Three views, appointment moves, absences and closures with the impact shown before saving.
Customer records
Visit history, average frequency and notes, with the phone number as identity.
Reminders on WhatsApp
It arrives where the shop already writes, with a personal link to cancel or move without calling.
The counter tablet
Screen always on, a sound on every booking and cancellation, exit protected by a PIN.
Booking completable without creating an account
Double bookings blocked by the database, not by an application check
Old site addresses redirected one by one: no bookmark landing on an error page
No cookie banner, because nothing on the site makes one necessary
Technologies
Other projects
Got a similar project?
Tell us where you're starting from. We'll reply with a clear proposal and realistic timelines, no commitment.