Skip to content
jasonm.dev

Product

Wito

A booking app for a solo, mobile barber in Grand Rapids. Customers book a haircut, and he comes to them.

Responsive product walkthrough · no forms or customer data

Tech stack

  • Next.js 14
  • React 18
  • JavaScript
  • CSS
  • Browser localStorage

This stack reflects the current prototype. Persistence is browser-only; no production backend is connected yet.

The problem

An open time is not always a reachable time.

Most booking software assumes a fixed location. For a traveling provider, an open slot is not necessarily a reachable slot: a morning booking in one neighborhood can make the next appointment across town physically impossible. Availability has to account for the route, not just the calendar.

Walkthrough

The same booking run, in two languages.

Silent capture of the live prototype: the home page, the English and Spanish toggle, then booking through date and time selection. Every value shown is fictional prototype data, and no booking is submitted.

Customer booking flow

From an open day to a confirmed appointment.

The flow carries a customer through date, time, details, review, and confirmation. Every value shown here is fictional prototype data; the case study does not submit a booking or expose a customer record.

Wito mobile booking calendar for choosing a service date
01 · Choose a reachable date
Wito mobile booking screen for choosing an available time
02 · Choose an available time
Wito mobile booking form filled with fictional prototype contact and address information
03 · Add demo details
Wito mobile booking review showing fictional prototype appointment information
04 · Review the appointment
Wito mobile confirmation screen showing a completed prototype booking
05 · See confirmation

Barber operations

A separate view built for the working day.

The barber app keeps today’s route, the next seven days, client history, and unconfirmed bookings within thumb reach. Customer and operator experiences stay separate because their jobs, devices, and privacy needs are different.

Screens use prototype demo records. Private addresses and access notes are intentionally excluded from this case study.

Wito barber view showing an unconfirmed booking and the day's stop count
Today · acknowledgment stays visible until confirmed
Wito barber view showing the next seven days of bookings
Week · route-aware schedule
Wito barber view showing prototype client history
Clients · service history

Structural decisions

01

Two users, two apps

Customer booking and barber operations started together, then split around different users, devices, and privacy needs. The barber view is designed for quick, one-handed use between appointments.

02

A simpler travel model first

Real-time routing adds more infrastructure than this early prototype needs. Area-based day clustering provides a practical starting point while route-aware availability remains a later step.

03

Seen matters more than sent

A delivered notification does not mean it was seen. Unacknowledged bookings stay prominent and become more urgent until the barber confirms them.

04

No manufactured credibility

Wito is an apprentice building his book, with no reviews yet. The product uses real photography and states that honestly instead of inventing experience or testimonials.

State today

Working frontend. Not a live service yet.

The customer booking flow and barber view are complete, clickable React prototypes. The customer experience is mobile-first and bilingual, with genuinely localized English and Spanish dates and copy. Both sides currently store separate data in the browser, so a customer booking does not yet reach the barber. No paying customer has used the product.

Start a project

Have a project taking shape?

If you’re working through a website or product problem, I’d be glad to hear what you’re building.