How to build a creative studio landing page with Claude Code

Rule of thumb: if the site is a formality (somewhere to send people who already know you, updated twice a year) rent one and spend the time on the work instead. If your site is how you get hired, if the reel is long or in more than one cut, or if you can already name the thing you want that a builder will not let you do, that is the case for owning it. The tell is whether you have ever described your own site as "fine".

* Two honest ways to make a contact form reach you, and both start free. A hosted form endpoint is the no-server route: Basin’s free tier covers one endpoint and 50 submissions a month with basic spam filtering, and its own page notes that filtered spam does not count against that allowance. Paid plans start at $12.50/mo billed yearly for 250 submissions. If you would rather own the whole path, one small function of your own plus an email service does it. Resend sends 3,000 emails a month free, capped at 100 a day. A studio fielding a few inquiries a week fits inside either free tier indefinitely.

Either way the page is yours, and nothing about it is metered: not the length of your reel, not the number of projects on it, not how many people are allowed to edit it. The difference is who does the work: pay someone up front, or describe what you want and build it yourself.

Prices and rates from usebasin.com, resend.com, developex.com and claude.com, checked August 2026.

Nothing here is worth memorizing. The first three just need to exist on your machine. The last is a URL you paste in at step 05. From step 01 on, you say what you want and Claude Code runs the commands.

1. 01

   Get the project running

   An empty page running on your machine, with the styling and animation libraries already in and a short notes file so Claude Code keeps your conventions from here on.

   PromptSet up the projectCopy

   Scaffold a new React 18 + Vite + TypeScript project, add Tailwind and Framer Motion, and set up a dark theme as CSS custom properties (background, foreground, muted text, and two or three accent colours) rather than hard-coded values scattered through the components. No database and no environment variables: this project reads none. Then write a short CLAUDE.md saying this is a single-page site for a creative studio, listing the sections it will have in order, and naming those colour tokens so later edits use them instead of inventing new ones.

   The notes file is what stops section six choosing a different grey from section two.

2. 02

   Put every section on the page before you style any of them

   Stack all of it unstyled, with real headings and placeholder body text, and scroll through it once. Ordering problems are obvious at this stage and expensive to see later, once each section is beautiful enough to be defended.

   PromptLay out the pageCopy

   Build the page as stacked full-width sections in this order: hero, featured work, awards, about, services, team, contact, footer. Give each one an id so in-page links work, and add a fixed navigation bar whose links scroll smoothly to them, with a hamburger menu under about 768px. Keep it deliberately plain for now: real headings, placeholder paragraphs, grey boxes where images and video will go. I want to argue about the order before anything is styled.

   Grey boxes are the point. A section that only works because its photograph is good is a section in the wrong place.

3. 03

   The hero, which is also the page’s speed

   The most-looked-at part of the page and the one that decides whether anyone sees the rest of it. Build it with the still frame and the reduced-motion path in the same pass, not as a later cleanup, because both change how the markup is put together.

   PromptBuild the heroCopy

   Build the hero: a full-screen background video, muted, looping, autoplaying, with a poster image shown until the video can actually play and a dark overlay so text stays readable over any frame. Over it, one headline, one supporting line, and a single button. Make the fixed nav transparent at the top of the page and give it a solid background once the visitor has scrolled about 50px. Then handle prefers-reduced-motion: when it is set, do not play the video at all. Show the poster image and keep every other element exactly where it is. Point the video at a local file in the public folder for now so I can swap in the real one.

   The poster image is not a nicety. Without it the first thing a visitor on a slow connection sees is a black rectangle.

4. 04

   The work, the proof, and what you sell

   Four sections in one go, because they share a shape: a heading, a grid, and a reveal as they come into view. Do the motion once here as a reusable piece rather than four times slightly differently.

   PromptBuild the work and proof sectionsCopy

   Now fill in four sections. Featured work: one large video with the project name, the client, and a short paragraph beside it, built so I can swap between an embed and a self-hosted file without rewriting the layout. Awards: a responsive wall of logos or laurels with the award name and year as accessible text, not baked into the images. Services: a card per service with a name, a sentence, and room for a price or a from-price. Team: a grid of photographs with a name, a role, and one line each. Then write one reusable scroll-reveal wrapper (a short fade and rise as an element enters the viewport, disabled entirely under prefers-reduced-motion) and use it for all four rather than animating each section its own way.

   One reveal component is why the page feels composed. Four separate ones is why a page feels busy.

5. 05

   The form, and somewhere for it to go

   Everything above exists to get a visitor here. This is the step where a page with no backend needs one outside service, and where you find out whether the message really arrives, which is not the same as the form saying it did.

   PromptBuild the form and connect itCopy

   Build the contact form: name, email, what they want made, and a message, with the required ones checked before anything is sent and inline errors that say what is wrong. Then wire the submit to post to a hosted form endpoint whose URL I will give you, handle the failure case as well as the success case, and show a visible confirmation on the page itself, not a console message, and not something that vanishes before it is read. Add a hidden honeypot field that bots fill in and humans never see, and reject any submission that has it filled. Do not put anything secret in the code: the endpoint URL is public by design, and if a step needs a real secret, tell me and we will move that piece to a server function instead.

   Test it by actually submitting the form and checking your inbox. A green tick is a claim about a network request, not evidence that a human received an email.

6. 06
   Destination

   Make it fast, then publish

   The three passes that decide whether the page works for anyone who is not you: weight, contrast and keyboard access, and how the link looks when somebody shares it. Then it goes live.

   PromptTune itCopy

   Three passes, and tell me what you changed in each. Speed: report the size of every image and video, convert the stills to a modern format at sensible dimensions, lazy-load everything below the fold, make sure nothing but the hero loads eagerly, and tell me plainly if the hero video is too heavy rather than working around it. Accessibility: check every text colour against its background for contrast, restore visible focus outlines if any got styled away, confirm the whole page can be tabbed through in a sensible order, and check the reduced-motion path still leaves nothing missing. Sharing: set the title, description, and an Open Graph image so a pasted link shows a preview card. Then run a Lighthouse pass and give me the numbers before and after.

   PromptPublish itCopy

   Build the site for production and walk me through deploying it to a static host, then tell me what to check on the published URL rather than locally. I want to open it on a phone with wi-fi off and see how long the hero takes to appear. After that, list what to improve next in priority order, with the one thing you would do first.

   The phone-on-cellular check is the only one that tells you what a visitor actually gets.

Read this project the way a stranger reading its published files would. List every value that ends up in the built bundle and should not be public: keys, tokens, private URLs, anything left in a comment. Then list every request the finished page makes to a third party, what each one sends, and any cookie it sets. Finally, tell me what the contact form does with a submission, where that submission ends up, and what currently stops a bot filling it in a thousand times.

The one rule that matters: a static site has no secrets: if a value is in the project, treat it as published. Anything that must stay private belongs behind a function on a server, not in the page.

Any of these will serve the page. Two things to check rather than assume: whether the free tier permits commercial use, and what its bandwidth allowance is. A hero video changes that arithmetic completely, and a page that goes mildly viral is exactly when you find out. Read the plan terms for the host you pick, not just the headline price.

Neither of the first two stores anything you would call a database. They move a message from your page to your inbox, and that is the whole of this build’s server side.

Add a single serverless function to this project (the smallest one my host supports) that reads an AI provider key from an environment variable, accepts a short JSON request, calls the model, and returns the text. Do not let the key reach the browser bundle, keep the function to one file, and show me how to set that environment variable on my host rather than in the repository.

When the contact form is submitted, send the message text through the ai function and have it return a short structured summary: the deliverable, the timeline, any budget mentioned, and any references named, with "not stated" where the message does not say. Include that summary above the original message in whatever reaches my inbox, and never in place of it.

Go through every image and video on the page and draft alt text for each one (what is actually in the frame, in a sentence, not the file name) plus a caption track for any video that has speech. Put them in a single list I can edit before you write any of it into the code, since I know what the work is and you are guessing.

Read the whole page, then write five alternative versions of the hero headline and its supporting line: same claim, different emphasis: one leading on the craft, one on the outcome for the client, one on the kind of work we want more of, one shorter than everything else, one that names our niche outright. Keep each under twelve words and match the voice already on the page.

Each prompt above picks the model that fits the job. As a rule of thumb, that is Haiku for high volume, Sonnet for everyday writing, and Opus for deeper reasoning. Model names move faster than this page does, so check the current list in the Claude docs (linked in the references below) before you build. Send every one of these prompts through that same ai function, so one key and one set of rules governs all of them.