The problem
A barbershop with a full book loses customers quietly: the message lands on WhatsApp while the barber has a razor in hand, nobody answers within ten minutes, and the person books somewhere else. A paper diary sends no reminder the day before, and a no-show becomes an empty slot that never comes back.
What the market offers is the booking app. It solves the booking, but the shop becomes a profile inside another company's app, with the competitor showing up next to it and sometimes a commission on a customer who was already theirs. None of those apps gives the shop a site on its own domain, which is what shows up when someone searches on Google.
The constraints
The decisions
One codebase, one deployment per client
Each barbershop has its own deployment, its own content repository and its own domain, all served by the same codebase. What changes from one client to the next is configuration and content: brand colours come from the CMS and become theme variables, and every feature is switched on or off by an environment variable.
A single system holding every shop's data together. Discarded: one bug would show one shop's calendar to another, and the economies of scale only appear at a client count the product does not have yet.
The receptionist talks, the code acts
The language model writes answers from what the shop published in the CMS: prices, hours, address, services. Cancelling and rescheduling do not go through it. The system understands the request and the action is carried out by fixed rules that check the real calendar before confirming anything. Switching model provider is configuration, not a rewrite.
Let the AI change the calendar on its own. Discarded: a confirmed slot that does not exist is worse than a slow answer, and it is the kind of mistake the customer finds out at the door.
The bot notices on its own when a human took over
The system keeps a list of every message it sends itself. When a message leaves the shop's number and is not on that list, someone typed it on the phone, and the bot stays silent in that conversation for two hours. That list is kept in one place shared by every server; back when each server had its own, the bot once ended up talking over the attendant.
A button in the panel to pause the bot. Discarded: it depends on someone remembering to press it mid-conversation, which is exactly when nobody remembers.
The confirmation only claims what was actually sent
On booking, the slot is checked again against the barber's calendar, and if someone took it first the person is told, instead of two bookings in the same slot. After that, calendar, email and WhatsApp are independent channels, each reporting its own status. If WhatsApp is down the rest still holds, and the confirmation screen does not promise the message that never went out.
One single success confirmation. Discarded: it hides one channel's failure behind the others' success, and the customer waits for a message that never arrives.
The result
The product is ready to sell, with a complete demo barbershop at barbeariamodelo.samuelramos.dev: site, step-by-step booking, confirmation and reminder by WhatsApp and email, calendar invite, and a panel for owner, barber and front desk with a monthly report, a conversation inbox and a counter display screen.
Setting up a new client is a written runbook, not a project. The system is checked by more than 360 automated tests, and runs on free hosting with routines that renew the database before it expires, so WhatsApp does not disconnect.
There is no client barbershop in production yet, so there are no booking or no-show figures to show. The indicators that will measure the product are already defined: bookings per month through the site, and no-shows before and after the automatic confirmation.
tech sheet
- stack
- Next.js · TypeScript · Prismic · Google Calendar · Redis · Evolution API
- duration
- demo live in 9 days
- role
- Product, architecture and development