Inner Beauty Salon Platform

The public-facing side of the website needed to be simple.

Someone visiting a beauty salon website probably wants to do one of a handful of things:

• see what treatments are available
• check prices
• find an appointment
• book
• find the salon
• learn a little about the person providing the treatment

They shouldn't need to hunt through five menus and three paragraphs of marketing copy to do it.

So the new site is being built around a much clearer treatment and booking journey.

Customers can browse treatments such as nails, facials, waxing, massage and male grooming, with durations, prices and important information presented clearly.

The booking system then works around the salon's real opening hours and availability.

That sounds obvious, but it changes the website from being an online leaflet into something genuinely useful.

This is usually the point in one of my projects where the original brief begins to expand.

Not because I want to add features for the sake of it, but because I start asking questions.

What happens when someone cancels?

What happens when a regular customer wants the same treatment again?

What happens when someone phones rather than books online?

How does the owner see tomorrow's appointments?

How do patch tests fit into the booking process?

Can the website help fill an appointment that has suddenly become available?

Could it remind customers about appointments automatically?

And if all of that information already exists, could it give the owner a useful picture of how the business is performing?

Suddenly I wasn't really designing a website anymore.

I was beginning to design a small business system.

The direction I'm taking with the project is deliberately split into two very different experiences.

For the customer, it should feel like a calm, straightforward beauty salon website.

For the owner, there is a much more capable system sitting underneath it.

The idea is that the owner could eventually open the admin area in the morning and immediately see something useful:

• Today's appointments
• Next customer
• How much work is booked
• Any cancellations
• Customers waiting for an appointment
• New bookings

From there, she can manage the diary, add telephone bookings, block time out, update treatments and prices, manage opening hours and see customer history.

It shouldn't feel like enterprise software.

There doesn't need to be a wall of graphs, fifteen dashboards and a menu full of things nobody ever uses.

One of the areas I've enjoyed thinking through most is availability.

Instead of simply having a big Book Now button, I want the website to be able to surface useful information immediately.

For example:

Then someone could go straight into booking that slot.

There is also scope for treatment search, allowing somebody to type something as simple as massage or brows and immediately find the relevant services.

Again, none of this is particularly futuristic technology.

It is just removing little pieces of friction.

And for a small business, removing friction can be incredibly valuable.

Another part of the project I'm developing is a lightweight customer system.

Not a giant CRM.

Just the useful bits.

A customer profile could show:

• previous appointments
• upcoming appointments
• treatments they regularly book
• cancellations
• no-shows
• simple notes
• the ability to quickly book them in again

If somebody regularly books the same massage or pedicure, the system shouldn't make either the customer or the business start again from scratch every time.

A Book Again button might sound like a tiny feature.

But tiny features used hundreds of times are often the ones that matter most.

This led me onto another idea I really like: a waiting list.

Imagine the salon is fully booked on Saturday.

A customer wants a luxury pedicure, but there aren't any suitable times available.

Instead of simply losing that booking, they could join a waiting list and say:

Then if another customer cancels, the system could recognise that the newly available appointment matches somebody on the waiting list.

Initially that might simply alert the owner.

Eventually it could automatically notify the customer.

A cancellation suddenly becomes an opportunity to refill the diary rather than an empty hour.

That is the sort of feature that interests me far more than adding another fancy animation to the homepage.

The project is also making me think about what happens after an appointment.

A lot of websites concentrate entirely on getting someone through the door once.

But for a business like a salon, repeat customers are hugely important.

So I'm looking at ways the system could make returning easier.

After a completed appointment, a customer might be able to simply choose:

Book this treatment again

Appointment reminders could reduce forgotten bookings.

A follow-up could make it easy to leave a Google review.

Gift vouchers could eventually be purchased online.

Seasonal packages could be switched on without rebuilding the site.

The website begins to become part of the relationship between the business and its customers rather than just the place where they found a phone number.

The prototype has already helped me work through a lot of the user experience, but the next stage is the important one.

Real customer information cannot live in a browser pretending to be a database.

The production version will need proper authentication, a proper backend and sensible security.

I'm looking at using Supabase for things such as:

• customer records
• appointments
• treatments
• opening hours
• blocked time
• salon settings
• waiting lists
• gift vouchers
• authentication

There is also the potential to integrate services such as Stripe later for deposits, payments and vouchers.

That architecture gives the project room to grow without turning it into an unnecessarily complicated platform.

The more I work on projects like this, the more I realise that the part I enjoy isn't necessarily writing the website itself.

It's asking:

Why is this done this way?

What does the person using it actually need?

What happens before this screen?

What happens afterwards?

What annoying little task could disappear completely?

That is the same way I tend to approach engineering problems.

The interesting bit often isn't the thing directly in front of you.

It's the system surrounding it.

A booking button is easy.

Understanding what happens when someone books, cancels, returns, phones instead, needs a patch test or wants the same appointment four weeks later is where the project becomes much more interesting.

There is still plenty to build.

The roadmap currently includes:

• a proper backend
• secure admin login
• a redesigned daily dashboard
• customer profiles
• improved appointment management
• reminders
• deposits and online payments
• gift vouchers
• cancellation waiting lists
• treatment-specific pages
• stronger local SEO
• business insights
• a mobile-friendly admin experience

But the aim isn't to cram every possible feature into it.

The rule I'm trying to use throughout the project is simple:

What started as a request for a modern website is gradually becoming something much more useful.

And that's exactly the kind of project I enjoy working on.