Deploy and Close

Step 1: Set up Vercel

The site works locally. Every feature Yasmine asked for is built, tested, and verified. Now it needs to work on the internet.

In P1 you deployed to Netlify. This time you are deploying to Vercel. Different platform, same concept: your local code gets built and served from a URL anyone can visit. What changes between platforms is the configuration. What stays the same is the process of separating configuration from code.

Environment variables are the mechanism for that separation. A database URL, an API key, a feature flag, the site's public URL itself: these values differ between your local machine, a staging environment, and production. They do not belong in code. They belong in environment variables, set per environment.

Vercel uses a prefix convention: variables that start with VITE_ are exposed to the browser (the client can see them). Variables without that prefix stay server-side (never sent to the browser). This distinction matters. A public analytics ID is fine in the browser. An API secret is not.

Before directing Claude to configure anything, decide which variables need to exist and which side they belong on. If you skip this step, Claude will generate configuration that works but mixes public and private values, and you will not notice until something sensitive is exposed.

Direct Claude:

Initialize Vercel for this project. Set up environment variables with the correct separation: public variables (prefixed with VITE_) for anything the browser needs, server-only variables for anything that should stay private. Configure the build command and output directory for a Vite + React project.

After Claude finishes, check the configuration. Open the Vercel project settings or the local .env files. Verify that no server-side value is prefixed with VITE_. Verify that any value the browser needs does have the prefix.

Step 2: Deploy to staging

Staging exists because deploying directly to production without an intermediate check is a bet that nothing will break. Staging is where you find the problems that only appear outside your local environment.

Deploy to the staging (preview) environment:

vercel

Visit the staging URL Vercel gives you. Open the site on your laptop. Click through the product grid. Try each category filter. Open a product detail view. Check the custom work section. Navigate with your keyboard: tab through the filter buttons, open a detail view, close it with Escape.

If something breaks, the question is: is this a code bug or a configuration mismatch? A missing image that worked locally is probably a path issue in the build. A feature that worked locally but fails on staging is probably an environment variable that exists on your machine but was not set in Vercel. A deployment failure caused by an undefined environment variable is not a code bug. It is a configuration mismatch between environments. The fix is in the Vercel dashboard, not in the source code.

Step 3: Deploy to production

Once staging looks right, promote to production:

vercel --prod

Visit the production URL. This is the URL Yasmine's customers will use. Open it on your phone. The interactive features need to work with touch: tapping a filter category, tapping a product card to open the detail view, scrolling through detail photos, tapping the close button. If you built the click handlers with standard button elements and keyboard support, touch usually works. If something was implemented with mouse-specific events, it will not.

Check the product images on mobile. Are they loading at the right size for the screen? A phone with a 375px display should not download the same 1200px image a desktop monitor uses. The srcset and sizes attributes you checked in Unit 5 matter here: they tell the browser to choose the right image for the device.

Step 4: Handle Maya's feedback

Maya Torres, a senior frontend engineer, checks the deployed showcase. She sends a message:

Checked the showcase. Filter buttons don't have focus indicators. Keyboard users can't tell which one is active. Add a focus ring. Takes two minutes.

She is right. Tab through the filter buttons yourself. If you cannot see which button is focused, a keyboard user cannot either. Accessible interactive components require visible focus indicators, not just functional ones. A button that receives focus without any visual change works for sighted mouse users and fails everyone who navigates by keyboard.

Direct Claude:

Add visible focus indicators to the category filter buttons. When a user tabs to a filter button, it should show a clear focus ring (e.g., a 2px ring in the brand color or a contrasting outline). Test with keyboard navigation: Tab to each button and verify the focus indicator is visible.

After Claude finishes, test it yourself. Tab through the filter buttons. Each one should have a visible ring or outline when focused. Press Enter or Space to activate the selected filter. The focus indicator and the selection state should be visually distinct: "this button is focused" looks different from "this category is active."

Step 5: Add a health check endpoint

A health check endpoint is the simplest contract between a deployed service and everything that watches it: monitoring tools, load balancers, deployment pipelines. The endpoint answers one question: is the service running and able to do its job?

The answer needs to come from the service actually exercising its dependencies, not from returning a static 200. A health check that always returns "OK" without checking anything is like an employee saying "everything is fine" without looking. For this project, the dependencies are light: the product data loads, the components render. A minimal check that confirms the data source is accessible is enough.

Direct Claude:

Add a /health endpoint that returns a JSON response with status and timestamp. The endpoint should verify that the product data is loadable. Return 200 with {"status": "healthy", "timestamp": "..."} when the data loads, or 500 with {"status": "unhealthy", "error": "..."} if it fails.

After Claude finishes, check where the logs go. On Vercel, stdout and stderr from serverless functions go to the Vercel dashboard under "Logs." Locally, they appear in the terminal. Knowing where your platform sends logs is the first step in production diagnosis. If Claude added any console.log statements during this work, check them. Are they structured entries with useful context, or are they string messages like console.log("health check called")? AI defaults to console.log with plain strings. A structured log entry with a timestamp, severity level, and request context is the difference between useful production data and noise.

Step 6: Share with Yasmine

Share the production URL with Yasmine. She opens the site on her phone. She taps on a bag. She sees the stitching up close, the clasp from another angle. She filters by wallets. She reads the custom work section. She responds:

"This is exactly what I meant. They can explore, not just scroll. Thank you."

The project is complete from her perspective. What she asked for in the email is live on the internet. People can explore her work properly.

Step 7: Write the README

You wrote a README for P1. This time the README also describes the artifact creation pipeline you used. The project is not just the code. It is the planning documents that made the code possible: the PRD translated from Yasmine's email, the design decisions, the architecture, the CLAUDE.md governance file, the ticket breakdown. The README tells the story of how this project was built, not just what it does.

Direct Claude:

Write a README.md for this project. Include: project description (what the site is and who it's for), the deployed URL, the tech stack (React, TypeScript, Vite, Tailwind CSS, Vitest, Vercel), how to run the project locally, how to run the tests, and a section describing the planning artifacts in the planning/ directory (PRD, design decisions, CLAUDE.md, ticket breakdown). The README should explain that these documents were created before any code was written, and that the project was built from them.

Review what Claude produces. Does the README accurately describe the project? Does the deployed URL work? Does the planning section explain the pipeline without making it sound like a school exercise?

Step 8: Push to GitHub

The repository is the deliverable. Not just the source code: the planning artifacts, the tests, the README, the commit history. The commit history tells the story of the project: pipeline artifacts committed first, then component work, then tests, then security, then deployment.

Make sure the planning artifacts are in their own directory (the one your CLAUDE.md specified). Verify that the directory structure makes sense: planning documents alongside source code and tests. A professional repository where everything that produced the project lives together.

Commit any remaining changes and push:

git add -A

git commit -m "feat: deploy to Vercel and complete project"

git push origin main

Visit the GitHub repository page. The file listing should show the planning directory, the src/ directory, configuration files, and the README. The commit count tells the story of the build sequence.