How to build a website with an AI prompt

1. Prepare a short project brief

Before pasting the prompt, state the audience, the main action visitors should take, and the pages you actually need. Supply your business or project name, draft copy, and available images. If you are editing an existing project, ask the assistant to inspect it before replacing its structure.

For a new project, agree on an implementation approach that you can run and maintain. Claude or Codex needs the relevant project access and development tools; a text conversation by itself is not a running website. Keep unresolved decisions visible instead of letting the assistant invent them.

• What should a visitor understand or do on this page?
• Which content and assets are final, and which are placeholders?
• Does the project already use a framework or component library?
• Which interactions must work in the first version?

2. Translate the reference into behaviors

Paste the English prompt and add your project-specific requirements separately. If references are available, give the assistant access through tools its environment supports. Describe the important states in words as well: the opening view, a scrolled view, an open menu, and the narrow-screen layout.

For a video, identify the moment and behavior you want to reproduce. Does an object rotate continuously, follow the pointer, or move with scrolling? Does a headline animate once or every time it enters view? These distinctions give you something concrete to check later.

3. Resolve asset dependencies early

Ask the assistant to list any images, fonts, videos, icons, or 3D assets needed by the proposed implementation. Check which ones you have and which require a substitute. A missing hero image or model can affect composition more than a small difference in spacing.

If a reference needs real 3D geometry, make that requirement explicit. Agree whether to use a supplied model, build simple geometry, or choose a different treatment. A placeholder can keep development moving, but label it clearly so it is not mistaken for the final result.

4. Build, run, and correct one issue at a time

Have the assistant create the first working version and run the project's build checks. Open the page yourself or use the browser tools available in the development environment. Compare the implementation with your requirements at the same viewport size as the reference before judging finer details.

Write corrections as observations and desired outcomes. For example: the menu covers the primary button on a narrow screen; make the menu dismissible and keep the button reachable. Specific feedback is easier to verify than asking the assistant to make the whole page feel more polished.

5. Check the complete visitor journey

Walk through the page as a visitor, including states that do not appear in the preview. Follow links, open and close menus, use the keyboard, and try a small screen. For forms or integrations, distinguish a visual interface from a connected feature that has actually been tested.

Review real text, image cropping, loading behavior, and motion together. When the design is acceptable, prepare hosting and production settings as a separate step. Confirm the published page again, because a local preview alone does not verify the public website.

• Content: correct names, useful copy, and no accidental placeholder text.
• Interaction: working destinations, clear focus, and usable touch controls.
• Layout: no clipped headings or horizontal overflow at narrow widths.
• Motion: readable content and a suitable reduced-motion experience.