From Prompt to Prototype: Use Claude and Cursor to Build a Landing Page in 2 Hours
Build and review a landing-page prototype with Claude and Cursor using a clear brief, staged prompts, and a deployment checklist.
Use Claude to draft the page content, then use Cursor to assemble and refine the frontend. Work against a time-boxed plan, but treat the two-hour target as a workflow goal rather than a guaranteed result.
Setup and constraints
Start with a short product brief. Describe what the product does, who it helps, and what action the visitor should take.
Include these details:
- The page’s main message
- The problems the product addresses
- The benefits to explain
- The desired call to action
- Any approved wording or brand rules
- The required content structure
Choose a project framework and styling approach you can maintain. Keep the prototype focused on one page, and avoid adding features that are not needed to test the core message.
Before prompting the tools, write a short checklist of what the finished page must include. This will help you keep the workflow focused and make review easier.
Generate the copy with Claude
Give Claude the product brief and a clear page structure. A practical prompt is:
“Create copy for a SaaS landing page with a hero section, problem statement, feature-benefit section, social proof area, pricing section, and call-to-action footer. Use second-person language, direct sentences, and a plain tone. Avoid unsupported claims. Return the copy as structured sections that can be transferred into a frontend.”
Review the draft before using it. Check that it:
- Explains the product without unnecessary jargon
- Connects each feature to a user benefit
- Avoids invented statistics, testimonials, and customer claims
- Uses only approved product names and offers
- Makes the main call to action clear
- Fits the intended brand voice
Ask for focused revisions rather than asking for a complete rewrite each time. Useful requests include:
- Shorten the headline while preserving the main benefit.
- Replace jargon with plain language.
- Turn the feature list into problem-and-benefit pairs.
- Remove unsupported claims and generic praise.
- Make the call to action specific.
- Add headings that describe each section’s purpose.
- Check that the copy follows a consistent voice.
- Return the final copy in the requested structure.
Do not let generated testimonials, logos, pricing, or performance claims enter the page as facts. Add placeholders when the design needs them, then replace them with approved material.
Build the page with Cursor
Open the landing page in Cursor and give it the approved copy, framework requirements, and page structure.
A practical instruction is:
“Build a responsive landing page from the supplied copy. Use semantic HTML, clear heading levels, accessible landmarks, descriptive link text, keyboard-visible controls, and appropriate image placeholders. Separate the page into reusable components where useful, and explain the files you create.”
Ask Cursor to explain the main files and the page structure. You should be able to identify where to change:
- The headline and introductory copy
- Navigation and calls to action
- Feature cards
- Pricing or plan content
- Testimonials
- Footer links
- Images and other assets
Review the generated code before continuing. Look for missing headings, inaccessible controls, unclear labels, broken links, and content that does not match the approved brief.
Request small, specific changes. For example:
- “Add a proper page header.”
- “Connect each section heading to its section with an accessible label.”
- “Make navigation links descriptive.”
- “Ensure buttons have visible keyboard focus.”
- “Check that the heading structure makes sense.”
- “Replace placeholder customer quotes with neutral placeholders.”
- “Use approved wording for every call to action.”
Do not assume the generated code is correct merely because it runs. Open the page in a browser and check the visible content as well as the code.
Refine the design
Work through the page section by section. Keep the visual hierarchy consistent and avoid adding decoration that competes with the main message.
Typography and spacing
Ask for a readable type scale, consistent line spacing, and enough space between sections. Keep headings related to the copy beneath them rather than selecting them only for their size.
Check the page on small and large screens. Make sure text remains readable, buttons do not overflow, and long words or links do not break the layout.
Feature section
Use a simple grid for the feature cards. Each card should contain a clear heading, a short benefit statement, and an appropriate icon or image placeholder.
Ask the tool to keep the layout flexible when content changes. Avoid embedding essential text inside images.
Pricing section
Use pricing information only when it has been approved. Keep plan names, features, and calls to action in editable text rather than hard-coding them into decorative graphics.
If pricing is not ready, label the area as a placeholder and remove any invented offers before publishing.
Images and assets
Use placeholders during the prototype stage. Replace them with approved images that have suitable alternative text.
Check image dimensions, cropping, loading behaviour, and display on small screens. Do not refer to a decorative image in alternative text unless it conveys information the visitor needs.
Review the page
Before deployment, review the page manually. Use this checklist:
- The headline explains the product’s main benefit.
- The visitor can understand the intended audience.
- Every feature is connected to a practical benefit.
- All claims are supported by approved information.
- Testimonials and customer names are genuine and authorised.
- Pricing matches the current approved offering.
- Navigation works on every page included in the prototype.
- The main call to action is visible and clear.
- Forms validate information and provide useful error messages.
- Headings follow a logical order.
- Controls can be reached and used with a keyboard.
- Focus indicators are visible.
- Colour is not the only way information is communicated.
- Images have appropriate alternative text or are marked decorative.
- The layout works on small and large screens.
- Placeholder content has been removed or clearly marked.
Deploy and test
Deploy the prototype through the hosting workflow available in your project. Before publishing, test the live page in a private or restricted environment if the content is not ready for public use.
After deployment, check the live URL rather than relying only on the local preview. Confirm that the build completed, the page loads, and the main navigation and calls to action work.
Ask Claude to review the page copy for clarity and unsupported claims. Ask Cursor to inspect the frontend for common structural and accessibility issues. Treat both outputs as suggestions: verify each issue yourself before accepting the change.
Run a browser accessibility checker and address the findings that apply. Then test keyboard navigation, forms, links, and responsive layouts manually. Automated checks can identify possible problems, but they do not replace a human review.
Final checklist
Use this before sharing the prototype:
- Approved product brief applied
- Unsupported claims removed
- Invented social proof removed
- Pricing verified
- Copy reviewed for clarity
- Code structure understood
- Keyboard navigation checked
- Mobile layout checked
- Image alternative text reviewed
- Live deployment checked
- Stakeholder or user feedback requested
FAQ
Can I use this workflow for a multi-page site?
Yes. Build the main landing page first, then repeat the process for secondary pages. Keep shared navigation, headings, components, and styling consistent across the site.
What if I do not know the framework?
Start with a small project and ask the tool to explain each generated file. You will still need to understand enough of the structure to review the page, maintain the content, and troubleshoot basic problems.
How do I handle images and real assets?
Keep the prototype simple with placeholders. Add approved assets near the end, then check their dimensions, alternative text, loading behaviour, and appearance on different screen sizes.
How do I keep the generated page accurate?
Provide approved source material, prohibit invented claims, and review every section before deployment. Replace all testimonials, customer names, pricing, logos, and performance statements with verified content or neutral placeholders.