The Nail Bar by Eve·2026·Website & business platform
A salon that runs on one phone.
Website, bookings and the business behind them — built so she still confirms every appointment herself.

The story
Eve runs her salon on her own, and she confirms every appointment personally over WhatsApp. That part was never the problem to solve — it was the thing to protect. So the product had to carry everything around it: the public site, the request flow, availability, pricing, and the numbers she runs the business on. I designed and built all of it, then handed it over with documentation so it keeps running without me.
- Role
- Product design & development
- Client
- The Nail Bar by Eve
- Year
- 2026
- Discipline
- Website & business platform
- Scope
My contributions
Database-level
Overlap protection
SQL + TypeScript
One pricing truth
Cookie-free
Visitor analytics
Chapter 01
What it does
A customer picks a treatment, a length and a moment, and sees the price build up as she goes. Eve gets a request — not a booking — and confirms it personally. Everything behind that exchange is the product: what can be offered, what it costs, what still fits in the day, and what the week is worth.
Customer
A request, not a booking
Six steps, roughly two minutes, with the price building live as the treatment and length are chosen. Nothing is confirmed until Eve says so.
Owner
The confirmation stays hers
The closing step is a personal WhatsApp message. The system prepares it; it never sends the appointment on her behalf.
Business
The numbers she needs
Expected revenue, occupancy and returning customers — the three things that tell a one-person salon whether the week is working.
Chapter 02
The problem
A one-person salon has no front desk. Every request, every price question and every schedule change lands on the same phone that is also doing the manicure. A conventional booking system would have made that worse, not better: it would have taken away the personal confirmation that makes her business hers, and handed her an inbox to manage instead.



Chapter 03
The decisions
Four choices shaped the build. Each one came from how the salon actually runs, not from what was easiest to implement.
Product
Keep the human confirmation
The WhatsApp approval is not a gap in the automation waiting to be closed. It is the product. Everything else was built around it.
Engineering
One source of pricing truth
The same pricing rules live in the database and in the application code, so a quote on the site and a total in the admin cannot drift apart.
Engineering
Protect the calendar in the database
Overlap protection is enforced at the database level, not in the form. It survives a double tap, a retry, and two people requesting the same slot at once.
Privacy
Count visitors without cookies
She gets the traffic numbers she needs. Her customers get no consent banner and nothing following them around.
Chapter 04
The whole salon, on one screen.
Customers see the cream-and-gold site. Eve runs the salon from the environment behind it — requests, agenda, pricing and the week's numbers, on the phone that is already in her hand. What follows is the real product, recorded in use. Customer names, phone numbers, the booking link and the private salon address were covered before the clips were encoded; nothing readable was ever in the file.
- Requests wait in one queue until she confirms them personally via WhatsApp
- The agenda knows treatment lengths, and the database refuses overlaps outright
- Appointment totals come from the same pricing rules the public site quotes with
- The approval message is drafted from a template, then sent by her
03 · Pricing
One pricing truth. Price, extra minutes and a maximum per add-on. The same rules the public site quotes with total the appointment here, so the two cannot drift apart.
Chapter 05
What shipped
The public site and the business environment behind it, live on her own domain.
- Public website with treatments, prices, portfolio and house rules
- Six-step booking request with live price build-up
- Add-on pricing for nail art, 3D flowers and gems
- Availability that accounts for treatment length
- WhatsApp confirmation as the closing step
- Admin environment with expected revenue, occupancy and returning customers
- Cookie-free visitor counter

Chapter 06
Launch and handover
The site went live on her own domain, delivered with a handover document covering what runs where, how to deploy it, and what is not finished yet. That document is the point: the product belongs to her, and it should keep working whether or not I am reachable.
Reflection
What I learned
Automate around the person, not over them
The instinct with a booking system is to close the loop and let it confirm appointments itself. Here the manual step was the most valuable part of the service. Finding that out first changed the whole design.
Put the rule where it cannot be bypassed
Validation in a form is a suggestion. The same rule in the database is a guarantee. For anything where being wrong costs a real appointment, it belongs in the database.
A handover is part of the product
Software that only its builder can operate is unfinished. Writing the handover forced me to name every loose end, which is a better final review than any checklist.





