He asked for a booking page. He needed a business system.

My barber was complaining while he cut my hair.

Not about the work. About the scheduling. Customers booked by messaging him on WhatsApp, others walked in, and he held the whole day in his head. Between conversations he was trying to work out whether the next hour was already taken. Sometimes he got it wrong and two people arrived for the same slot. Sometimes someone forgot entirely, remembered at the last minute, and turned up late to a chair that had already moved on.

So I offered to fix it, and he said yes.

What he asked for

A booking page. Customers pick a time, the time gets taken, and he stops carrying the day around in his head.

That was the whole brief. It would have been a perfectly reasonable thing to build, and it would have solved about a third of his problem.

What I found instead

Once I started asking how the shop actually ran, the scheduling turned out to be the visible part of something larger.

He had no records. Not messy records: none. He didn't know what the shop had spent in a month, what it had made, or what was left over. He and his father argued about it again and again, because there was nothing either of them could point to that would settle it.

He hadn't asked me to solve that. He hadn't mentioned it as a problem at all. It was just how things were.

Building the shop, not just the page

So the brief changed from "take bookings" to "run the shop", and the system grew around how a day there actually works.

The booking side came first. Customers choose a service, a barber, a time, and leave their details, and only open slots are ever offered. That was the whole point: the double-booking that started the conversation. Every booking comes with a private link the customer can use to reschedule or cancel without messaging anyone.

The shop side was built alongside it. The day starts from a Today view: the appointments and where each one stands, from checked in to done. Walk-ins can be added from the same place, because plenty of the shop's customers still just walk in. Each barber has a day and week calendar, with time blocked out for breaks, and every customer has a record with their visit history.

Then came the part he never asked for: staff and their working hours, the services and how long each one takes, product sales, expenses, and a monthly report that puts revenue, costs and profit on one screen. You can see what these screens look like in the NEXT system tour.

When I showed him, he said he felt like he finally had real management in his shop. About the expense tracking in particular, he said: finally I won't hear about this anymore.

That's the line I keep coming back to. The feature that meant the most to him was the one he never asked for.

The reminders come from a specific failure

Customers forgetting wasn't hypothetical. It had happened, and it costs twice: the slot sits empty, and the person who turns up late still expects to be seen.

So reminders go out 24 hours before an appointment and again 2 hours before. Those numbers aren't a default I copied from somewhere. The day-before reminder gives someone time to cancel so the slot can be filled. The 2-hour one is for the people who fully meant to come and simply lost track of the day.

There's a limit worth being honest about: reminders only reach customers who can be reached. Anyone who turns on notifications gets both. Anyone who leaves an email gets the 2-hour one by email. There's no SMS and no WhatsApp channel, so a customer who does neither gets no reminder at all.

The account question

He wanted customer accounts, with registration before booking, partly so he could collect dates of birth and send offers.

I pushed back. As far as I knew, no other barbershop in our city had a website like this. For a first-time customer, a registration form is an unfamiliar obstacle in front of something they currently do by sending a WhatsApp message, and some of them would simply not finish it.

We agreed on a rule instead: an account can make booking easier, but it can never be the price of booking. Accounts did arrive later, on exactly those terms. A customer can sign in with Google or Microsoft, or book as a guest with a name and a phone number, and a guest booking can be claimed into an account afterwards. The dates of birth and the offers never made it in.

He also wanted a WhatsApp chatbot. At the time, when we talked through what it would cost to build and run, he decided against it himself. The idea has come back since, as something we're planning rather than something that exists. I'd still rather a client drops a feature for a good reason than pays for one they don't need yet.

Where I was wrong

I had hidden the hero video on phones. It was a deliberate performance call: video is heavy, and a lot of his customers are on mobile data.

He wanted it visible. It's his shop and his brand, and the video is how he wants the place to feel before anyone reads a word. So I put it back on mobile the next day and kept one exception: visitors whose device asks for reduced motion get a still background instead. That setting isn't a preference, so it stays.

The build

The public site, the booking flow and the management side all run on Angular, with a Laravel API and MySQL behind them. Angular suited this shape of project. A booking flow is mostly form state and validation, and the management side is a lot of similar screens where an opinionated structure pays off.

The rules that matter live on the server. It decides the prices, the durations and which slots are free, and it re-checks a booking inside a transaction before saving it, so two people booking at the same moment can't both be given the same chair. The browser is never trusted with any of that.

Push notifications were the hardest part by a distance. They simply wouldn't arrive, with nothing useful to say why, and getting them reliable took more trial and error than I'd like to admit.

What running it taught me

A system that takes real bookings finds the cases a prototype never meets.

The one that stung most came in September. Some services block a barber's time completely and some don't, and when a booking mixed the two, the scheduling rules let two appointments land on the same barber at the same time. It was a real double-booking, the exact thing the system existed to prevent. I traced it, fixed it the next day, and the booking checks are stricter for it.

Other rules only appeared once real bookings were coming in. A booking for the next hour is a different thing from a booking for next week, so anything starting within 60 minutes is now a request that holds the slot until the salon accepts or declines it. That rule wasn't in the first version. It came from running the real thing.

What I'd do differently

Decide the full feature set at the start.

Customers could add an appointment to their calendar from early on, but real calendar sync, where a booking stays in someone's Google or Microsoft Calendar and updates when it changes, came later, once people were already booking. It works, but it was fitted around decisions that were made without it in mind. Adding small things later is fine. Discovering a whole capability late is not, and that one is on me, not the client.

What it cost

I price by feature and by what it adds to the business, not by the hour. The scope grew a long way past the original conversation, so I re-quoted openly partway through and explained what the extra work was. He agreed, because by then he could see what it was worth.

I'd rather do that than quietly absorb the work and resent it, or bill hours for a number nobody can sanity-check.

Where it stands

NEXT is live at next-lb.com, and it was already taking online bookings in July. In August it recorded 161 of them; in the first 25 days of September, another 252.

The booking flow is one page now instead of five: each step folds into a short summary once it's done, so a customer can see the whole booking and change any part of it before confirming. Customers can pick more than one service, change their services later without cancelling, and keep the appointment in their own calendar. A barber can have a login of their own that shows only their own day, and the management side installs on a phone like an app.

His own summary of it was: "You organized my whole business from A to Z, including parts I had not even thought about."

That last part is the whole story. He asked for a way to take appointments. What he got was the calendar, the records and the reports his shop had been running without, built around how the shop actually works rather than around the page he first described. Most of what it does now, nobody put in the original brief. It came from watching the day.

---

If you're running a business out of your head and a WhatsApp thread, the useful question usually isn't the one you'd think to ask a developer. It's worth finding someone who asks what else is broken.