Pemba's Booking System

Step 1: Set up the project

Open a terminal and navigate to your development directory:

cd ~/dev

Start Claude Code:

claude

Paste the setup prompt:

Create the folder ~/dev/web-dev/p5. Download the project materials from https://learnbydirectingai.dev/materials/webdev/p5/materials.zip and extract them into that folder. Read CLAUDE.md -- it's the project governance file. Open VS Code in the project directory. Install the Claude Code extension and the Live Server extension if they aren't already installed.

Once Claude finishes, you have the project workspace with all materials in place. The CLAUDE.md file gives Claude persistent context about the project -- what you're building, the tech stack, the ticket list, and the verification targets. Every session benefits from this file being loaded first.

Step 2: Read Pemba's message

Open materials/first-contact.md.

Pemba Sherpa runs a trekking outfitter in Kathmandu. His booking system lets customers see treks, book spots, and check their bookings. It works -- most of the time. The problem is what happens when his developer Raj pushes changes. The system crashes. Last October, during peak Annapurna season, it went down for two days.

His friend Arjun told him Docker helps. Pemba doesn't know what Docker is. He knows the system breaks, and he needs it to stop.

Notice what Pemba tells you and what he doesn't. He describes the problem clearly -- the system breaks when changes are pushed. He doesn't describe the tech stack, how Raj deploys, or what "breaks" means technically. Those gaps are yours to fill.

Step 3: Understand the existing application

Before you can containerise anything, you need to understand what you're packaging. Explore the starter application in materials/starter-app/.

The system has three components:

The backend (starter-app/backend/) -- an Express server that serves the API. Routes for listing treks, viewing trek details, creating bookings, and listing bookings. PostgreSQL for the database. Winston for structured logging with request IDs, routes, and methods in every log entry.

The frontend (starter-app/frontend/) -- a React application built with Vite. Trek listings, detail pages, a booking form, and a booking lookup by email. Tailwind CSS for styling. Talks to the backend via API calls.

The database (starter-app/database/) -- PostgreSQL schema with two tables: treks (4 seed treks including Annapurna Base Camp, Langtang Valley, Everest Base Camp, and Poon Hill) and bookings (6 sample bookings from customers in Germany, Japan, Sweden, and India).

These three pieces run independently right now -- you start the backend, start the frontend, and they talk to each other. When you containerise them, each component gets its own container.

Step 4: Ask Pemba about the gaps

Open the chat with Pemba. He described the problem -- the system breaks when Raj pushes changes. He didn't describe:

• How Raj currently deploys. Does he push directly to the server? Does he test first?
• What the tech stack looks like from Pemba's perspective. Does he know it's React and Express, or is it just "the system"?
• Who else uses the system. His office staff? His guides?
• What "breaks" means specifically. Does the whole thing go down? Just the booking page?

Ask targeted questions. Pemba answers what you ask. He mentions his office staff (Dawa, Mingma, Sonam) who use the system daily. If you ask about infrastructure, he might mention the unreliable internet during monsoon season. If you ask about payments, you learn about the NPR and USD currency handling.

Docker, in terms Pemba would understand, is like packing the entire application into a box that works the same everywhere. Your laptop, the server, another server. If the server breaks, you take the box and put it somewhere else. The system doesn't care where it runs because the box carries everything it needs.