Slotwise
Online booking for barbershops, studios and clinics.
A booking page for each business, where customers pick a service, a professional and a free time in three steps, plus a dashboard the front desk runs the day from: a calendar with drag to reschedule, appointments, customers, services, team, working hours, a reminders log and analytics. Two demo businesses: a barbershop in Brooklyn and a Pilates studio in Austin, each in its own time zone.
Book at /b/ironside-barbers or /b/lumen-pilates; nothing is charged and reminders are only logged. Dashboard at /dashboard with the password demo (read-only).
- Active build time
- 2 h 42 min
- Agents
- 5 agents
- Tests passing
- 113
- Lines of code
- 14,304
- Runtime dependencies
- 5
Built by an App Factory squad of 5 Claude Code agents inside Cadrix: a leader on Opus that planned, reviewed and shipped, and four specialists (Backend, Data, Frontend and QA) working in parallel from the sixth minute. 2 h 42 min of active work, with no line of code written by a person. The wall-clock time was longer, about 28 hours (Oct 7, 19:58 to Oct 8, 23:59 UTC), because the Claude subscription hit its usage limit twice and the run sat paused for 20 h 57 min and then 4 h 22 min; each time a short message told the leader to resume. Times come from the agents' session logs, the canvas recording, the git history and the build log.
Watch the squad work
Time-lapse of the Cadrix canvas, one frame every 30 seconds, played in 31 seconds. The two usage-limit pauses are cut out and marked. The last 19 minutes were not filmed, so the final frame is the canvas as the squad left it, captured afterwards. Near the start, focus mode shows every agent at once.
What it does
- Public booking page per business: cover, team, hours and rating, then a three-step flow (service, professional and time, your details) with a sticky summary on desktop and a bottom bar on phones
- Availability engine that respects working hours, breaks, days off, buffers between appointments, minimum notice and the booking horizon, with an "any professional" option; safe across daylight-saving changes
- Manage link for each booking: reschedule or cancel inside the business's window (12 h for the barbershop, 24 h for the studio), plus a calendar file (.ics) to download
- Dashboard calendar by week or day, coloured by professional, with drag to reschedule and conflicts refused before they happen
- Appointments, customers, services, professionals, working hours and days off; SMS and e-mail reminders 24 h and 2 h before, logged and never sent
- Analytics in SVG: appointments, revenue, average ticket, no-show rate, occupancy by professional, weekly revenue and busiest hours, with a table view; seeded with 150 customers and about 2,200 appointments
How it was built
- 0–6 minLeader: scaffold, API contract, data model and plan in the team note, a release script; all four specialists dispatched at once
- 6–51 minIn parallel: Data wrote the schema and the seed, Backend the availability engine, auth and every API route, Frontend the landing, booking flow and manage page, QA the Playwright harness and API tests. First release live at 51 min
- 52 minFrontend's request timed out with the dashboard half-written, and the run paused on the usage limit for 20 h 57 min
- 52–80 minResumed: the leader saved Frontend's uncommitted dashboard as a checkpoint and re-dispatched it; dashboard released, then reviewed live at 390 and 1440 px
- 80–143 minFix round by Frontend, Data and Backend in parallel, then a polish round; full suite green. Then the usage limit hit again and the run paused for 4 h 22 min
- 143–162 minResumed: phone layout for working hours, QA's final verification, one blocker fixed with a regression test, final release
Problems the agents solved
- Frontend's first request timed out with about 3,300 lines of dashboard code uncommitted, and then the usage limit paused the whole run. On resume, the leader checked that the code still built and typechecked, committed it as a checkpoint and sent Frontend back to finish from there. Nothing was lost.
- The second usage-limit pause (the chat shows "You've hit your session limit") cut off two tasks before they changed anything. When the limit reset, the leader checked git for anything left unfinished and re-sent both.
- The leader's own walkthrough of the first full release found six problems: the phone booking page stretching to 848 px, eight items overflowing the phone dashboard menu, blank screens while loading, an unreadable week calendar, future days almost fully booked and a reminders log taking 680 ms. Frontend, Data and Backend fixed them in parallel; the log now answers in about 6.5 ms.
- QA found that cancelling a booking failed in production: the browser sent a JSON content type on requests with no body, and the server answered 400. It was fixed on both sides.
- In the final verification QA blocked the release: the dashboard menu used relative links, so each click stacked onto the URL. The leader made them absolute links two minutes later, and QA's new regression test passes at desktop and phone size.
- Smaller catches along the way: Data and Backend had each written time-zone helpers, merged into one; the sample-data fallback was removed so production cannot hide API failures; and a test helper that picked a slot earlier than requested was fixed once more times opened up.
Stack
Node 22Fastifynode:sqliteReactReact RouterViteVitestPlaywright
More screens
Build yours the same way.
A private machine with Claude Code, Codex and Pi on one canvas.