How to build a creative studio landing page with OpenAI Codex

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 learn.chatgpt.com, checked August 2026.

Nothing here is worth memorizing. Two installers, a plan, and later a URL. From step 01 on, you describe a task and Codex runs the commands inside whatever permissions you have set.

1. 01

   AGENTS.md first, scaffold second

   Codex reads AGENTS.md at the start of every task, so writing it before the scaffold means your section names and colour tokens are loaded before any file exists to contradict them. Both happen in one task.

   PromptSet up the projectCopy

   Start by writing an AGENTS.md at the project root. The stack is React 18, Vite, TypeScript, Tailwind, and Framer Motion. This is a single-page marketing site for a creative studio, with no backend at all (no database, no authentication, no environment variables) so do not add one, and say so in the file. Fix the vocabulary too: the sections are hero, work, awards, about, services, team, contact, and colours come from a small set of CSS custom properties rather than literal values. You load that file automatically at the start of every later task, so none of it needs repeating. Then scaffold the project against it and start the dev server once to prove it boots before you stop.

   Naming the sections here is what stops task four calling the same thing "portfolio" and "showcase" in two files.

2. 02

   Get the whole page standing up, ugly

   Every section in order with placeholder content, styled as little as possible. Read this diff for structure rather than appearance. The markup Codex chooses here is what the next four tasks build on.

   PromptLay out the pageCopy

   Build the page as stacked full-width sections in this order: hero, featured work, awards, about, services, team, contact, footer. Each gets an id, and a fixed nav links to them with smooth scrolling and collapses to a hamburger under about 768px. Deliberately unstyled beyond layout: real headings, placeholder paragraphs, and plain grey blocks where images and video will go. Show me the diff before anything else, because the element structure here is what four later tasks will be built on top of.

   A page that reads correctly with no styling at all is a page whose reading order is right for a screen reader too, which saves an argument in the last task.

3. 03

   The hero, built with its fallbacks in the same task

   Adding a poster frame and a reduced-motion path afterwards means rewriting the hero. Ask for all three at once and the diff is one coherent piece of work rather than three that fight.

   PromptBuild the heroCopy

   Build the hero as one task, with its fallbacks included rather than added later. A full-screen background video (muted, looping, autoplaying) with a poster image displayed until playback can actually start, and a dark overlay so the text stays legible over any frame. Over it, one headline, one supporting line, one button. The fixed nav is transparent at the top and gains a solid background after roughly 50px of scroll. Under prefers-reduced-motion the video must not play at all: show the poster and leave every other element exactly where it is. Point the source at a local file in the public folder so I can swap the real one in. Then tell me, in the diff summary, which parts of this would need rewriting if I later moved the video to a third-party embed.

   That last question is worth asking now. Swapping a self-hosted file for an embed is a five-minute job if the hero was built for it and a rebuild if it was not.

4. 04

   Four sections that share one motion component

   Work, awards, services, and team have the same underlying shape. The thing to check in this diff is that Codex wrote the reveal animation once and reused it, rather than four near-identical variants that will drift.

   PromptBuild the work and proof sectionsCopy

   Four sections in one task. Featured work: one large video with the project name, the client, and a short write-up beside it, structured so an embed and a self-hosted file are interchangeable. Awards: a responsive wall of laurels or logos, with the award name and year as real text rather than pixels in an image. Services: a card per service with a name, a sentence, and space for a from-price. Team: a grid of photographs with a name, a role, and one line each. Write the scroll-reveal animation as a single reusable component (a short fade and rise on entering the viewport, fully disabled under prefers-reduced-motion) and use it in all four. If you find yourself writing a second reveal implementation, stop and tell me why the first one did not fit.

   Ask it to point at the one place the animation is defined. If it cannot, there is more than one.

5. 05

   Narrow your permissions before this one

   The one task in this build that touches an outside service and the one where a mistake is visible to strangers. Worth scoping Codex down to this task rather than leaving it whatever you set for routine section work.

   PromptBuild the form and connect itCopy

   This task connects the page to an outside service, so narrow your permissions to it rather than keeping whatever was set for routine edits. Build the contact form (name, email, what they want made, message) validated before submit, with inline errors that say what is actually wrong. Post it to a hosted form endpoint whose URL I will give you, handle the failure path as carefully as the success path, and show a visible confirmation on the page that does not disappear before it is read. Add a hidden honeypot field and reject submissions that fill it. One rule: nothing secret goes in this repository. The endpoint URL is public by design. If any part of this needs a real secret, stop and tell me, and we will move that piece behind a server function instead.

   Read this diff properly. It is the only code on the page that sends anything anywhere.

6. 06
   Destination

   Hand the long passes to a cloud run, then publish

   Compressing assets and working through contrast and focus order are long, mechanical, well-scoped jobs, close to the ideal shape for a cloud task you check back on. Read the diff before it merges, then take it live yourself.

   PromptTune itCopy

   Three passes, and I want a summary of what changed in each rather than a silent commit. Weight: list the size of every image and video, convert stills to a modern format at sensible dimensions, lazy-load everything below the fold, keep the hero the only eager load, and say plainly if the video is simply too heavy instead of working around it. Accessibility: check every text colour against its background for contrast, restore focus outlines if any were styled away, confirm a keyboard can reach everything in a sensible order, and re-check that the reduced-motion path leaves nothing out. Sharing: title, description, and an Open Graph image so a pasted link renders a card. This is a long, self-contained job. If it suits a cloud run better than an interactive session, say so and hand it back as one diff.

   PromptPublish itCopy

   Build for production and walk me through deploying to a static host. Then tell me what to verify on the live URL rather than locally, starting with opening it on a phone with wi-fi off and timing how long the hero takes to appear. Finish with what to do next in priority order, and which of those you would hand to a cloud task rather than work through with me.

   Nothing about a static build is environment-specific, so if it works locally and fails live, the cause is almost always the video or the form endpoint.

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 should pick whichever model tier fits the job: a fast, lower-cost model for high-volume work, and a stronger reasoning model for anything that weighs tradeoffs against each other. Codex’s model names change faster than this page does, so check OpenAI’s current model line-up (linked in the references below) before you build, rather than copying a name you saw once. Keep all of it behind that same ai function, so one key and one rule set covers every feature you add.