777-1: FlexBook (7 Subagents, 7 Predictions, 0 Faith)
Published: December 10, 2025 - 5 min read
Welcome to Project 5 of the 777-1 experiment! If you missed the previous projects, go check out Kinetic Canvas, GoalStack, MotorMatch, and EarthenCraft first. Otherwise, let's keep moving.
This project is where state isolation is about to be tested. When you have multiple trainers, each with their own availability, selecting a time slot for Trainer A should NOT affect Trainer B's display. Sounds obvious, right? My subagents are already placing bets on how badly this goes wrong.
What is FlexBook?
FlexBook is a booking platform where fitness enthusiasts browse trainers by experience level, view availability, and schedule personal training sessions.
Think of it like finding a tutor, but for deadlifts. You want to work on your form? Browse trainers by experience level (beginner-friendly, intermediate, or advanced). Found someone interesting? Click their profile, check their rates, see their available time slots. Pick a slot, book the session. Done.
The key challenge here is that every trainer has their own calendar. Their own rates. Their own availability. When I'm looking at Marcus's 2:00 PM slot on Tuesday, that has absolutely nothing to do with Jessica's 2:00 PM slot on Tuesday. They're independent schedules. Simple concept. Notoriously difficult to implement correctly.
Application Category: Booking / Scheduling
Complexity Tier: Complex
The Prompt: Finding the Goldilocks Zone
The starting prompt I'll be using for this application is:
Build me a trainer booking app called FlexBook where people can find and schedule sessions with personal fitness trainers. Users should filter trainers by experience level—beginner-friendly, intermediate, or advanced. Clicking on a trainer should reveal their rates and open time slots. Picking a time slot books the session. Keep the interface uncluttered so the booking flow feels quick and straightforward.
Use a material design approach with #0D9488 (teal) as the primary color, #CCFBF1 (mint) as secondary, and #EF4444 (coral) as an accent.
Again, this is my attempt at finding the goldilocks zone for context engineering. But here's what makes this project particularly tricky: booking systems have hidden complexity that the prompt doesn't mention.
What happens when two users try to book the same slot simultaneously? What happens if a trainer updates their availability while someone is mid-booking? How does the system know WHO is booking the session if I never mentioned login?
These are the kinds of questions that separate a demo from a product. And I deliberately left them out of the prompt.
Meet the Critics
You already know my seven subagents from the previous projects, so I won't repeat the full introductions. Quick refresher:
- Amber Williams - Mobile-First Perfectionist
- Kristy Rodriguez - "Does It Actually Work?" Enforcer
- Micaela Santos - Design System Guardian
- Lindsay Stewart - Accessibility Advocate
- Eesha Desai - State Management Specialist
- Daniella Anderson - Code Quality Specialist
- Cassandra Hayes - Feature Detective
The Predictions
I gave them the prompt. I asked them to imagine what the general-purpose subagent would build. Here's what each one expects to find:
Amber Williams (Mobile-First Perfectionist):
The calendar component was designed for exactly one screen width. That screen width is not yours.
Kristy Rodriguez (Functionality Enforcer):
Book an appointment. Receive confirmation. Check the trainer's calendar. Your appointment does not exist. It was a beautiful moment you shared together.
Micaela Santos (Design System Guardian):
The trainer cards use circular avatars. The calendar uses square date cells. The time slots use rounded rectangles. We have achieved geometric chaos.
Lindsay Stewart (Accessibility Advocate):
The calendar is a grid of clickable divs. None of them are keyboard accessible. Users who can't use a mouse simply cannot have personal trainers.
Eesha Desai (State Management Specialist):
Book with Trainer A. Book the same slot with Trainer B. Both confirmations succeed. Schrödinger's time slot exists in two states until someone shows up.
Daniella Anderson (Code Quality Specialist):
Time is stored as a string. Date is stored as a different string. Comparing them requires parsing, which happens differently in three separate components.
Cassandra Hayes (Feature Detective):
You can book a session with a trainer you've never met for a time that might not exist without logging in or providing contact information. The trainer will simply sense your presence, I suppose.
Zero Faith, Maximum Entertainment
This project hits different because it exposes three interconnected problems that booking systems always face.
Problem 1: State Isolation
Eesha's prediction is the one I'm most curious about. When you have multiple entities (trainers) each with their own state (availability), keeping those states properly isolated is surprisingly hard. Selecting a time slot for Trainer A should only update Trainer A's state. But if the general-purpose subagent uses a single global state object for "selected slot," suddenly clicking on Jessica's 3:00 PM updates Marcus's display too. I've debugged this exact issue in production. It's maddening.
Problem 2: Time Handling
Daniella is already bracing for the time/date nightmare. Calendars are deceptively complex. You need to store dates. You need to store times. You need to compare them. You need to display them. And if you're storing them as strings (which, let's be honest, the AI probably will), you're going to have parsing inconsistencies across components. "2:00 PM" in one place, "14:00" in another, "2:00pm" in a third. None of them match when you try to compare.
Problem 3: User Identity Without Auth
And there's Cassandra, back at it again with the identity question. This is MotorMatch all over again, but arguably worse. At least with a marketplace, anonymous browsing makes some sense. But a booking system? You're scheduling a real appointment. At a real time. With a real person. Who is the trainer supposed to meet? How do they know you booked? The prompt says "picking a time slot books the session," but books it for whom?
I'm genuinely curious whether the general-purpose subagent will add some kind of contact form to the booking flow (a reasonable assumption), leave it completely anonymous (chaos), or hallucinate a login system I never asked for (technically solving the problem but exceeding the prompt).
Kristy's prediction is also devastating. A confirmation that doesn't actually persist is the worst kind of bug because the user thinks everything worked. They show up. The trainer has no record of them. Awkward.
What's Next
Stay tuned for the next post where I introduce WealthView, a financial dashboard. My subagents have thoughts about chart accessibility. Spoiler: still no faith.
As always, thanks for reading!