FICTIONAL BUSINESS DEMO / BOOKING + INTEGRATION BOUNDARIES
Fade
District.
A clear path
to choosing a chair.
A fictional barbershop site with a three-step local scheduler and a separate external booking-tool mode.
your chair.
- 01 Service
- 02 Barber
- 03 Time
Not booked.
FRONT-END DEMO
NO RESERVATION CREATED
- My contribution
- Design, development
& deployment
- Context
- Demo · Fictional barbershop
July 2026 account
- Built with
- React · TypeScript · Vite
Tailwind CSS · Static Worker
01 / THE BUILDBuild around booking a chair
Fade District is a fictional barbershop website with one clear direction: services, barbers, prices and shop information lead toward choosing an appointment.
The project pairs that presentation with two booking modes. One is a three-step React scheduler that demonstrates the interaction. The other lets a visitor try an existing Calendly or Cal.com link inside the site's booking section, as described in the original write-up.
The distinction matters. The built-in scheduler has no booking backend and does not persist appointments. A finished-looking selection flow is not a reservation system.
02 / THE BUILDService, barber, time
The local example below follows the three choices described in the original: choose a service, choose a barber, then choose a time. Use Back to revise a choice or restart the example.
THE THREE-STEP FLOW
Try the choices. Keep the boundary.
A local explanation of the built-in scheduler, separate from any external scheduling tool.
- 1Service
- 2Barber
- 3Time
Choose a service
Fixed example services.
Choose a barber
Fictional names, not a real staff roster.
Choose a time
Example times on a sample day—not live availability.
No appointment booked.
You have tried the selection flow. No calendar, booking record or notification was created.
Choose an example service to continue.
Read the explanation without interacting
The source built-in scheduler asks for service, barber and time. The documented version is front-end-only and does not persist bookings. The external scheduler mode is a different path; this figure never loads it. Back lets an earlier choice be revised, and restarting clears the local example.
The names and slots in this explanation are fixed sample data, not the shop's original catalog or live availability. There is no appointment created, no calendar request and no notification. The final screen is a local summary.
03 / THE BUILDBring an existing scheduling tool
The second mode is aimed at showing how the website could sit around a tool an owner already uses. The original article describes pasting a Calendly or Cal.com link into the demo rather than replacing the scheduler outright.
The excerpt does something narrower than its “valid embed URL” comment suggests: it trims the input and adds https:// when neither lowercase HTTP prefix is present. That is formatting, not validation. It does not establish which hosts are allowed or whether a service can be embedded.
This portfolio explanation never loads the supplied URL. The article includes an inspector that lets you see exactly how the string changes, without opening an external site.
04 / THE BUILDA small, typed content source
The documented stack is React 19, TypeScript, Vite and Tailwind CSS v4, with static assets on a Cloudflare Worker. Services, barbers and shop information live in a typed data.ts file rather than a CMS.
The page also includes a side-by-side explanation of message-based booking and scheduler booking. It is a way to discuss the workflow with an owner; it is not evidence that the demo reduced missed appointments or increased sales.
05 / THE BUILDWhere the original stops
Persistent booking and email notifications remain unfinished in the documented version. It also proposes replacing the static work-grid images with an Instagram feed.
Those integrations are still separate work. What exists in the documented project is the booking-focused site, the local selection flow and the configurable external-tool mode.
Source, dates, and what this page verifies
This rewrite describes the supplied fictional-business project and its article published July 17, 2026. The original publication date and canonical source address are preserved. The original application and current deployment have not been audited.
New miniatures are explicitly illustrative, not screenshots or full reproductions. All teaching inputs stay in memory. No booking tool, enquiry service, message provider or outside page is loaded by an interaction. Original code excerpts remain unchanged and are displayed rather than executed as application code.
The named source limits and exact explanation of each new model are recorded in docs/batch-4/SOURCE-REVIEW.md. No business, medical, conversion or performance outcome was measured for these demos.