How to build a creative studio landing page with Replit

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

Everything above stays inside the one browser tab, including the published page. The only thing outside it is wherever the contact form sends to, and that can wait until step 05.

1. 01

   Decline the database, settle the palette

   The Agent is good at provisioning a backend and will suggest it. Saying no in the first message, and spending that message on the theme instead, is what keeps this build as simple as it actually is.

   PromptSet up the projectCopy

   This is a single-page marketing site for a creative video studio and it has no backend at all (no database, no authentication, nothing stored) so please do not add a database or offer to provision one, even though this workspace can. Start with the theme alone: one place that defines a near-black ground, a light foreground, one muted grey for secondary text, and two accents. A display face for headings and something ordinary for body. Then show me an empty page carrying only the fixed nav, so what I approve is a palette rather than a finished-looking section.

   A landing page that acquires a database because one was offered is a landing page with something to back up, migrate, and eventually pay for.

2. 02

   Every section, plain, before anything is styled

   Get the whole page standing up and scroll it in the running preview. Take a checkpoint when the order is right. That is the version you will want back the first time a redesign goes sideways.

   PromptLay out the pageCopy

   Build the page as full-width stacked sections in this order: hero, featured work, awards, about, services, team, contact, footer. Each gets an id so the nav scrolls to it, and the nav collapses to a hamburger menu on small screens. Keep it deliberately plain for now: real headings, placeholder paragraphs, grey blocks where images and video will go. I want to scroll the running version and settle the order before anything is styled.

   Ask for a checkpoint once the order is right. Everything after this is visual work, which is the kind you undo most.

3. 03

   The hero, and its fallbacks

   The section that decides whether anyone sees the rest of the page. Ask for the poster frame and the reduced-motion path in the same request, because both change how the hero is put together.

   PromptBuild the heroCopy

   Build the hero. A full-screen background video, muted and looping and autoplaying, with a dark overlay keeping the text legible over whatever frame is showing, and a still image standing in until playback can begin. Over it a headline, a supporting line, one button. The nav is transparent at the top of the page and takes a solid background once I have scrolled roughly 50px. Then the case that decides whether this page is usable at all: for a visitor whose system asks for reduced motion, do not play the video, show the still, and leave every other element exactly where it was. Placeholder file for now, and tell me where mine goes.

   Check it in the running preview rather than describing what you expect. Autoplay is one of the things that behaves differently once it is actually running.

4. 04

   Four sections, one shared animation

   Work, awards, services and team share a shape, so build them in one request with one reveal component between them. If your plan allows two Agent sessions at once, this and the form are genuinely independent, though watch that they do not both touch the shared layout.

   PromptBuild the work and proof sectionsCopy

   Four sections, and one animation between them. Featured work: a single large video with the project name, the client, and a short write-up beside it, put together so an embed and a self-hosted file are swappable. Awards: a responsive wall of laurels, name and year as real text rather than part of the image. Services: a card each, carrying a name, a sentence, and space for a from-price. Team: photographs in a grid, with a name, a role, and one line apiece. Then write the reveal once, as a shared component (a brief fade and rise on entering the viewport, disabled outright under reduced motion) and use it in all four rather than giving each its own.

   Take a checkpoint before you start adjusting spacing. Visual polish is where a session produces the most changes you will want to walk back.

5. 05

   The form, and the decision that picks your deployment

   This step has a consequence unique to Replit: posting to a hosted endpoint keeps the whole site publishable as static files, while receiving submissions through a function of your own means something has to run. Decide here rather than at the publish step.

   PromptBuild the form and connect itCopy

   Build the contact form (name, email, what they want made, a message) validated before it submits, with inline errors that name the actual problem. Then connect it, and before you write anything tell me which of these you are doing and what it does to publishing. One: post straight to a hosted form endpoint whose URL I will add through Secrets, and this app stays a folder of files with nothing of mine running behind it. Two: add one small server route here that takes the submission and forwards it through an email service, key in Secrets, which means something of mine has to execute whenever a visitor arrives. Either way: treat a failed send as carefully as a successful one, leave a confirmation on screen long enough to be read, add a hidden honeypot field, and drop anything that fills it. No database.

   Whichever you choose, submit the form and check your inbox. A confirmation on screen is a claim about a request, not proof a person got an email.

6. 06
   Destination

   Make it fast, then publish from here

   Three passes on weight, contrast and sharing, then Publishing takes this same project live on its own domain. The deployment type follows from step 05 rather than being a fresh decision.

   PromptTune itCopy

   Three passes, with a note on what changed in each. Weight comes first, because the workspace preview flatters it: tell me what every image and video costs in kilobytes, re-encode the stills to a modern format at the size they display rather than the size they were exported, defer everything under the fold, leave the hero as the only eager load, and say outright if the video is too big rather than engineering around it. Then contrast and keyboard: each text colour against its background on this dark palette, focus rings left visible, the tab order walked end to end, the reduced-motion version confirmed complete. Last, the shared link: title, description, and an Open Graph image so a pasted URL becomes a card.

   PromptPublish itCopy

   Take me through Publishing. Based on what we did in step 05, tell me which deployment type this app actually needs and why. If the form posts to a hosted endpoint, I want to know whether a Static deployment covers everything here. Then cover who the page is visible to on day one and how to connect my own domain. After that, tell me what to check on the published URL rather than in the workspace preview, starting with opening it on a phone with wi-fi off and timing the hero.

   The workspace preview is served from the machine that built the page. What a client gets is a different thing, and the phone-on-cellular check is the only one that shows you which.

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.

All four are Replit rather than a third party, so the choice is shape rather than vendor, and unusually, this build wants the simplest of them. Check who the page is visible to before the first release, since Publishing is what sets that.

Whichever of the first two you pick also picks your deployment type above, which is the one place these two decisions are not independent.

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.

A cheap model is plenty for most of the prompts above. Save Pro’s stronger models for the one or two spots where the extra reasoning actually pays for itself. Add any provider key through Replit’s own Secrets tool rather than hard-coding it, and keep every AI feature behind one server-side function so a single key covers the whole app.