Day 4 — Animate + expand

Open localhost on desktop. Scroll the homepage top to bottom and write down everything that looks off. Don't fix anything yet — just capture the list. Things to check: blur effects, image scaling, spacing, alignment, overlay opacities.

Open dev tools and switch to a mobile width (or open it on your phone). Same exercise: scroll, note what's broken. Common mobile issues: scroll bars where there should be sliders, content cut off, scaling looks weird, layouts that don't centre properly.

Cmd + Shift + 4 on Mac. Crop tightly to the problem area.

Don't worry about technical language. "The blur is fading at the bottom but should be strongest at the bottom" works just as well as anything more technical.

I don't know why, but it seems like the blur is fading out towards the bottom. The blur should be strongest at the bottom and then fade out towards the top.

Sections like testimonials and services often default to horizontal scroll bars on mobile, which feel broken. Ask Claude to convert them into proper slider experiences.

On mobile, this section turns into a scroll bar with the tops cut off. Make it a proper slider experience instead, where I can swipe through and see all items fully.

Don't add animation polish on top of a broken layout — you'll just be hiding bugs. Walk through both desktop and mobile one more time and confirm everything looks right at rest.

Don't try to animate everything at once. Start with the nav, since it's the highest-impact and most visible.

If you don't say GSAP, Claude might reach for Framer Motion, Anime.js, or CSS-only animations. Specify GSAP up front.

Use GSAP for the animation. I want some nice hover effects on the nav bar links, a nice button hover effect, and I want the mobile navbar to be animated, not just static instant opening like it does now.

Vague is fine. "Give me a nice hover effect" lets Claude propose something. If you like it, keep it. If not, ask for something else.

Just paste "all clear" at the end. Claude does a sanity check on whether it actually understood what you described before building anything.

Animations can break differently on different screens. Always test both before moving on.

Examples: "the button hover effect is boring, do something else", "if I quickly hover off the button it goes all white", "I want 15 pixels more space between Specter and the paragraph below". Specific issues = specific fixes.

Once you spot a few related things, list them in one go. Example: "Make the nav sticky on scroll, no background, switch text from black to white when over dark sections, and fix the button white-flash issue when you hover off quickly."

Subtle underline appears under each nav link on hover. Apply to all top-level links.

Buttons follow the cursor slightly and have a colour-changing slide-up effect on hover. Used on every "Let's talk" button across the site.

Mobile menu opens smoothly rather than instantly. Looks far more refined.

Nav stays visible as you scroll. No background colour. Text and buttons switch from black to white when over dark sections (e.g. the deliverables image), and back to black when over light sections.

On scroll, the word "Harvey" drifts left, "Specter" drifts right. The "Hello, I'm" label follows Harvey but slightly slower. Background image grows. Creates a really dynamic hero.

Text fills in colour as you scroll, locked to scroll progress (scrubbing). Premium-feeling effect with very little code.

Box parallaxes off to the left as you scroll past it. Disabled on mobile to avoid breaking the layout.

Image starts blurry, sharpens to fully clear by the time you're scrolled about 50% past it. Subtle but adds depth.

Each row has a thin grey line that grows wider on hover, while the deliverable name shifts slightly.

Project cards lift or shift on hover. Tells the user the card is interactive.

Testimonial cards drift slightly as you scroll past them, adding rhythm to the section.

Footer is fixed-revealed: as you scroll to the bottom, it appears from underneath the page rather than just being below it. Easy way to make a long page feel more complete.

Once the homepage exists, Claude knows the design language: fonts, spacing, animation patterns, classes. Generating new pages becomes dramatically faster.

Make me an about page based off the homepage.

If it's good enough, move on. If not, list specific issues. Either is valid — don't get stuck perfecting one page when others don't exist yet.

When the page should pull from CMS, say so up front.

Now do the same thing with a new projects page. Make sure to use the Sanity data.

Once Claude clearly knows what it's doing, bundle requests. Saves tokens and keeps the design consistent.

Make me a news page, make sure everything is in Sanity. Then make me a contact page. Then make a modal for Let's talk that pulls open the contact form.

It's better to have all pages at 80% than one page at 100%. Get the whole site to a good baseline, then circle back to polish.

Example: the sticky-reveal footer doesn't work as well on a black-background projects page. Tell Claude to swap it for something else on that specific page.

When asking Claude to build a new page that pulls from the CMS, ask for the schema in the same breath. Saves a round trip.

Make me a news page, add a news article schema to Sanity, and make sure the page pulls from it.

If you don't have specific field requirements, Claude will infer reasonable ones (title, slug, image, body, date, etc.). Refine afterwards if needed.

If the client has specific fields they need (price, SKU, category, related products), list them in the prompt. Avoids re-doing the schema later.

You don't need to manually create fields anymore — but you can still tweak ordering and add helper text directly in the studio interface (or ask Claude to).

Sanity Studio picks up new schemas on save. Refresh localhost:3000/studio to see the new content type appear.

A form needs a backend handler to actually deliver emails. Claude generates the markup; you bring the handler.

Julian's pick. One-time $25 payment for 50,000 submissions, no subscription. Better bot protection than the Webflow default. Site: formspark.io

Formspark gives you a unique URL for that form.

Submissions arrive in your Formspark dashboard and to your email.

For brand new projects with no users, push direct to main is fine. GitHub history is your safety net.

Can you push everything to main now?

Open Vercel → Deployments. You'll see a new build kick off in a minute or two.

Visit your live URL. Walk through each page. Check the animations work, the CMS pulls correctly, and the form submits (if you wired up Formspark).

Visit yoursite.vercel.app/studio. If you haven't registered the studio host yet, do that now — see Day 3 troubleshooting.

Sometimes the best workflow is "make this section feel more dynamic" and seeing what comes back. You can always refine. Specificity isn't a virtue when you don't have an opinion yet.

Generic AI websites look generic because the prompt was generic. Starting from a custom-designed homepage means the AI has a real design language to extend across new pages — that's why the about/services/news pages look intentional rather than templated.

Adding "all clear" at the end of a long prompt tells Claude to verify it understood the request before building. Catches misunderstandings early.

You can spend a week perfecting one page. Don't. Get the site to 80% across all pages, ship it, then refine based on feedback. Most clients can't tell the difference between 80% and 95% anyway — they care that it exists and works.

If a client paid for 10 hours, use the 10 hours. Just don't spend them on the wrong things. Faster generation means more time for craft (animations, refinement, copy) instead of fighting with code.

You don't HAVE to start from a Figma. If you're confident, you can describe the vision in prose and let Claude propose. Figma is a better starting point for client work; vibe-design is great for personal/experimental projects.