Local Retail · Booking OS · Revenue Operations
Hoosier Boy Barbershop
I treated the problem as a dual-sided product in one Next.js codebase.
Most barbershops stitch together group chats, paper books, and consumer scheduling apps. Signal: Dual-sided owner + client product
Dual-sided owner
+ client product
NSHR validation
+ deposit gating
Real-time revenue
projection
Problem / System
Dual-sided business OS — owner Command Center plus conversion-first client booking, with rules for premium slots and deposits.
Most barbershops stitch together group chats, paper books, and consumer scheduling apps.
The Challenge
Most barbershops stitch together group chats, paper books, and consumer scheduling apps. Double bookings, invisible no-shows, and owners who only see revenue after the week ends.
The structural issue is that client booking and back-of-house operations are treated as separate products — so the shop gets a pretty calendar for guests and a spreadsheet for the business, with nothing trustworthy in the middle.
Hoosier Boy Barbershop needed both sides in one system: almost-zero friction for clients, and a live operational and financial pulse for the owner and barbers — including rules that match how the shop actually prices and protects time.
The Approach
I treated the problem as a dual-sided product in one Next.js codebase. The client path is conversion-led: service-first navigation, staff selection (Jimmy or Nate), mobile-first slot picking — no account wall.
The business logic encodes real shop rules. Premium extended services require two consecutive atomic slots with correct pricing. NSHR installation stays behind a completed consultation with deposit logic so long vacancies do not land on the business.
On the owner side, the dashboard answers what matters today: appointments, expected revenue, completion rate, and flagged issues. Barbers update Arrived / In-Service / Completed so the floor state stays honest without side channels.
What got rebuilt
Client Booking Engine
Service-first flow with staff-specific booking, real-time availability per barber, and mobile-first UX — designed to protect intent before friction kills it.
Command Center Dashboard
Owner view for the day and week: appointment load, projected revenue, completion rate, and exceptions (no-shows, cancellations) in one surface.
Operational Rules Engine
Encoded premium slot validation, NSHR consultation gating, and deposit triggers so scheduling software matches revenue protection, not generic calendar defaults.
Supabase + Next.js Architecture
Postgres-backed appointment state with auth on the admin side, deployed on Vercel with server actions for overlap validation and optimistic client updates.
The Process
How the system got built
Discovery
Mapped shop services, barber roster, premium offerings, and financial exposure on long appointments.
Dual-surface build
Shipped client booking and owner dashboard against one schema and shared business rules.
Hardening
Stress-tested slot logic, deposits, and edge cases (overlaps, cancellations) before go-live.
The Outcome
The shop replaced fragmented tools with one source of truth. Owners see projected revenue before the week closes; clients book their barber without generic "next available" abstraction.
The build proves that when operational logic is specific — NSHR gating, premium slots, deposits — a custom platform outperforms one-size scheduling SaaS.
Hoosier Boy's broader engagement (brand, site, discovery) already moved bookings and local rankings; this system is the operational layer that makes high-complexity services shoppable without administrative chaos.
What This Means For You
If your service business is bending Square or Calendly around rules those products were never meant to represent, you are paying for workarounds forever. I build the system that matches your actual operating model. That is what I build.
Primary proof route Hoosier Boy Barbershop
Ready to build scheduling software that respects your real rules?
Let's talk about what that looks like.