Hair Studio One
A booking platform for a Groningen barber — clients reserve and cancel through an email link, and the owner runs his own shifts and client history from a lightweight admin.
Clients book and cancel themselves; the owner stopped juggling a phone and a notebook.
- Role
- Solo
- Timeline
- 2024
The business problem
A barber in Groningen — Rene, Hair Studio One — ran his bookings by hand: phone calls, and whatever he could keep in his head. That meant double bookings, forgotten slots, and no history of who had been in or what they'd had done. My job was to get the calendar out of his head and into something both he and his clients could actually use.
The constraints
- My first commercial project (2024) — one real paying client, and my first taste of what "in production" actually means.
- Solo, small budget, one barber. The whole thing had to be simple enough for one non-technical person to run day to day.
- Clients won't sign up. Someone booking a haircut isn't going to create an account and remember a password for it.
What I built and why
A booking site on Firebase with a lightweight admin. The owner opens and closes his own shifts and sees a client card with history — who came, when, and for what. Clients pick a slot, book, and get a confirmation email; that email carries a link that lets them cancel without ever logging in. The admin sits behind a single-key login — no user database, because there is exactly one admin.
Technical decisions, with the cost of each
Decision 1 — a single admin key instead of a full auth system.
Exactly one person ever touches the admin: the owner. Building real accounts, roles, and a password-reset flow for a single user is effort spent on a problem that doesn't exist. So admin access is one secret key, checked on the server.
The cost: it doesn't scale past one admin, and a key is only as safe as where it's kept — no per-user audit, no easy rotation. For a one-barber shop, that's the right amount of auth. (Two years on and unmaintained, this is exactly the layer that aged — more on that below.)
Decision 2 — cancellation by a tokenized link in the email, not a client login.
A client who booked once shouldn't need an account just to cancel. Each booking's confirmation email contains a unique tokenized link; opening it cancels that booking and frees the slot. One booking, one link, no password.
The cost: the token is the credential — anyone with the link can cancel that booking, so it has to be unguessable and ideally time-limited. In exchange, the client has zero friction, which is the whole point for a walk-in business.
The result — honestly
- It ran for a real barber and did the job it was built for: clients booked and cancelled themselves, and the owner stopped double-booking.
- I no longer maintain it. The client changed requirements faster than it made sense to keep supporting, and we parted ways — a normal end to a small engagement, not a failure.
- A lesson I actually kept: it's built on Firebase, and two years without maintenance was enough for the auth layer to age — today the admin login no longer works cleanly. That's a real cost-of-ownership lesson about BaaS: managed services move you fast, but "managed" still means someone has to keep the lights on. I'd make the same Firebase call again for a project this size — I'd just be clearer up front about who owns the upkeep.
- No metrics — I never instrumented bookings, so I won't invent numbers.