Deployment

Step 1: Deploy to Netlify

The site is verified. html-validate reports 0 errors. Lighthouse scores clear 90 across the board. Everything works locally. Now it needs to be somewhere Yasmine can actually see it.

Netlify is a hosting platform that serves static sites from a global CDN. The Netlify CLI lets you deploy directly from the terminal — no web dashboard, no dragging files into a browser. One command pushes your local files to production and gives you a URL.

That one command hides real machinery. Behind netlify deploy --prod, Netlify hashes your files, uploads them to edge servers distributed across multiple continents, provisions a TLS certificate so the site loads over HTTPS, configures DNS so the URL resolves, and sets up CDN caching so repeat visits load fast. You didn't configure any of that. The defaults are good — and they're defaults you can't inspect yet. That's fine. Knowing the machinery exists is enough for now.

HTTPS is not optional on the modern web. Browsers flag HTTP sites as insecure, search engines penalize them, and some APIs refuse to work without TLS. Netlify enforces HTTPS by default on every deploy. You benefit from a security decision you didn't have to make.

Direct Claude to run T7. The acceptance criteria in materials/CLAUDE.md specify deploying to Netlify with the CLI. Claude will install the Netlify CLI if needed, authenticate, and run:

netlify deploy --prod

Watch the terminal output. You'll see a sequence of steps — file hashing, upload progress, and then a URL. That URL is the deployed site.

Step 2: Visit the live site

Open that URL in your browser. This is not localhost anymore. The page is loading from a server you've never touched, over a network connection to a domain that didn't exist five minutes ago. Anyone with the URL can visit it right now.

The shift matters. On localhost, the site existed only on your machine. At this URL, it has a life independent of whether your laptop is open. The site is serving requests right now — to you, to anyone who has the link, to web crawlers indexing it for search engines. It continues to exist after you close your terminal.

Open the URL on your phone. This is the real test. Yasmine's buyers browse on their phones — a gallery owner checking pieces between meetings, a private collector scrolling during a commute. If the site doesn't work on a phone screen, it doesn't work for the people who matter most.

The gap between "works on my laptop" and "works on my phone from a production URL" is not a testing failure. It's a category difference. Production introduces variables that don't exist in development: network latency, different browsers with different rendering engines, screen sizes you never tested locally, DNS propagation delays. A site that looked perfect on your machine can behave differently in the wild.

Step 3: Check production

Walk through the live site systematically. This is verification, the same way html-validate and Lighthouse were verification — but manual, against the deployed version.

Check each page:

• index.html — the portfolio gallery loads, images display at correct sizes, captions are readable
• about.html — the process page loads, Yasmine's craft story is intact, navigation works back to the gallery
• contact.html — the form has all three labeled fields, the form submits (Netlify Forms handles submission on the deployed site — it won't work on localhost)

Check navigation between all three pages. Every link should work. Open the browser console (F12, Console tab) and look for errors — red text means something is broken.

A static site with no backend, no database, and no user input still has a security surface. The HTML source is public — anyone can view it. Comments in the code may contain internal references. Default server headers may disclose what platform you're using. None of this is dangerous for Yasmine's portfolio site, but it's worth knowing that "static" does not mean "invisible."

Netlify provides basic analytics — page views, unique visitors, top pages. These describe traffic, not health. A site can have rising traffic and be partially broken. Or it can have zero errors and serve no one. Traffic metrics tell you who showed up. They don't tell you what they experienced.

Right now, nothing is watching this site for errors. If an image path breaks tomorrow, if a CSS file fails to load, if the form stops submitting — you won't know unless you visit and check manually. The absence of error messages does not mean the absence of errors. At this stage, that's expected. Later projects add monitoring. For now, the deployed site is running on trust.

Step 4: Share with Yasmine

Send Yasmine the deployed URL. This is the first time she sees her work online — not a mockup, not a screenshot, but a live site she can open on her own phone and share with customers.

Yasmine responds:

Oh, c'est magnifique! The photos — they look exactly like the leather when you hold it in the light. The warm colors, the cream background... it feels like my workshop. And the process page — it reads like I'm talking about my own work, which is exactly right. I've already sent the link to my cousin in Lyon. She's been asking me for years how to show people what I make.

One small thing — could we add a little map showing where the workshop is in the medina? People always get lost trying to find me. The alley doesn't have a sign, and even with directions, first-time visitors end up at the spice market instead.

She loves the site. The colors, the photos, the way the process page captures her voice. Then she asks for something new — a map to help visitors find the workshop in the medina.

This is a scope addition. Not a failure of planning. Not a sign that the original brief was incomplete. Scope additions are a normal part of professional work. Clients see their project live and think of things they didn't think of before. Yasmine never needed a map until she imagined sending real people to the URL.

The map gets handled in the next unit. For now, the site is deployed, Yasmine has seen it, and the work is live.