Joe's Barber Cide
A two-chair barbershop runs its whole day on its own website — booking, walk-ins, barber portals, pay statements and 1099 prep — instead of renting a booking platform.
- My role
- Sole designer and developer — data model, booking engine, every role's interface, the payroll ledger, security review, and the production launch onto the shop's own domain.
- Built for
- Barbershops & salons
- Current status
- Live on the shop's own domain. Owner acceptance of the signed-in areas is in progress.
- Built with
- Next.js · Supabase (auth + Postgres) · Drizzle migrations · Vercel Blob · QR codes
The story
What problem existed, and what we built.
The problem
The shop's booking lived on a third-party platform. That platform owned the appointment list, the customer history and the relationship, charged for the privilege, and stopped at the moment the appointment was made. Everything after that — who is working, what each barber earned, what the shop owes at tax time — happened on paper and in someone's head.
What I built
A single system the shop owns outright. The public site takes the booking; the same system then runs the chair schedule, the walk-in queue, each barber's own portal, the rewards program and the payroll ledger that feeds 1099 preparation at the end of the year.
What it had to achieve
- Own the booking relationship instead of renting it
- Make the schedule truthful — never double-book a chair
- Give each barber a portal without giving them the whole shop
- Turn a year of cuts into a payroll record that survives tax season
The customer's experience
A customer lands on the site, picks a barber, and sees only the times that barber can actually take. They book in a few taps. If they'd rather walk in, they can see the queue instead. Next visit, the site already knows them and their rewards balance came along with them.
What customers can do
- Book a specific barber, service and time from any phone
- See real availability — the schedule is checked at the moment of booking, not after
- Join or check the walk-in list without calling the shop
- Browse barbers, services, prices and the lookbook
- A rewards balance that follows the customer across visits
The owner & staff experience
The owner opens one screen and sees the day. Each barber signs in and sees their own chair, their own appointments and their own pay statement — not the shop's books. When the shop needs to prepare 1099s, the earnings are already recorded, period by period, rather than being reconstructed from memory.
What the business can do
- Owner, Admin, Barber and Customer each see their own view and nothing else
- Appointment lifecycle — confirm, reschedule, no-show, complete — in one place
- Walk-in controls the front desk can actually work during a rush
- Pay statements per barber, snapshotted so history can't silently change
- A payroll ledger that adds up to what 1099 preparation needs
How it works
The system, explained without the jargon.
If a technical term is needed below, it's explained right where it appears.
One place where the truth lives
Every appointment, customer, service and payment record sits in a single database the shop owns. There is no second list to keep in sync, which is what makes the schedule trustworthy.
The availability engine
Before an appointment is created, the system re-checks the barber's real availability and writes the booking in one indivisible step. Two customers tapping 'book' at the same second cannot both get the chair.
Four doors, four keys
Owner, Admin, Barber and Customer are separate roles enforced at the database, not just hidden in the interface. A barber signing in cannot reach another barber's customers even by typing the address directly.
Payroll that snapshots
When a pay period closes, the earnings are frozen into a statement. Later edits to a service price don't quietly rewrite what someone was already paid.
Design decisions
The choices that shaped it — and why.
The booking is native, not a redirect
An earlier version fell back to the third-party platform when things got complicated. That fallback was removed on purpose: a booking flow that sometimes hands the customer to another brand is not the shop's booking flow.
The shop doesn't touch the money
The system displays each barber's own payment preferences and records amounts received. It deliberately does not process card payments — that was the right call for a shop where each chair settles its own way, and it keeps the system out of payment-compliance territory it doesn't need to be in.
The hero is the real chair
The homepage is built around a photograph of the shop's actual antique chair rather than stock barbershop imagery. Customers recognize the room they're about to sit in.
How it was built
Development process
- 1Mapped how the shop already worked — two barbers, one chair each, walk-ins mixed into a booked day
- 2Built the data model and the four roles before any screen
- 3Built the public site and the availability engine, then the appointment lifecycle on top
- 4Removed the third-party fallback once native booking held up
- 5Added the payroll ledger and rewards, then hardened customer-data access after a security review
- 6Launched onto the shop's own domain
Where it stands
Status & outcome
Current status
Live on the shop's own domain. Owner acceptance of the signed-in areas is in progress.
Outcome
The shop now owns its booking data, its customer list and its payroll record instead of renting them. What that is worth in saved platform fees and recovered rebookings has not been measured, so no figure is claimed here.
Related projects
You might also want to see
Want something like this for your business?
Tell me how your days go and what you'd like to stop doing by hand. I'll tell you honestly what would help.