Vibe Code Prompt to Build a SaaS Landing Page

A polished hero does not make a landing page production-ready. The page still needs to explain the product, send visitors somewhere useful, and handle forms, analytics, accessibility, and deployment without cutting corners.

This guide builds the marketing site for the feedback-board SaaS from the SignalRoom SaaS application guide. You can adapt it to another product, but keep the same rule: positioning, availability, forms, and analytics must describe the product that actually exists.

If the initial output keeps drifting into vague requirements, use the structure in How to Write Better AI Coding Prompts before adding more features.

Skip to the primary SaaS landing-page prompt, or start with the product brief below if your positioning is not settled yet.

What the SaaS landing page includes

The finished site includes:

• A responsive marketing homepage
• Clear product positioning and one primary conversion goal
• Product screenshots or honest placeholders
• Feature, workflow, use-case, availability, FAQ, and final CTA sections
• A working product-updates form with a distinct secondary purpose
• Server-side validation, spam controls, duplicate-safe storage, and an email adapter boundary
• Privacy and terms page structure
• Metadata, sitemap, robots, canonical URLs, Open Graph, and structured data
• Analytics events that answer useful questions
• Accessibility and performance budgets
• Automated checks and a production smoke test

Non-goals

The first version does not need:

• A custom visual page builder
• A full blog CMS
• A dozen animated backgrounds
• Fake testimonials
• Invented customer logos
• A consent banner when no non-essential tracking is loaded
• Claims such as “SOC 2 compliant” without evidence

Define the product before the page

For this example, the product is a customer-feedback SaaS for small software teams.

Audience: Small SaaS teams currently collecting requests through email, chat, spreadsheets, or issue trackers.

Problem: Feedback is fragmented, customers cannot see progress, and product teams repeatedly answer the same status questions.

Promise: One public place to collect, prioritize, and communicate product feedback.

Primary CTA: Start a free workspace.

Secondary CTA: View the public demo board.

Do this positioning work before asking an agent to design the page. Otherwise it will fill the layout with generic claims that could describe any software product.

Implemented stack

• React 19 with TypeScript strict mode
• Vite 7 for the client build
• Express 5 for same-origin form, analytics, and product APIs
• Supabase Postgres in deployment and PGlite in automated tests
• Vitest for client, API, migration, configuration, and metadata contracts
• Playwright with desktop Chrome, Pixel 7 emulation, and axe
• Vercel deployment

The marketing site lives in the existing SignalRoom repository. / serves marketing, /app preserves registration/login/onboarding, /b/:slug preserves public feedback boards, and /privacy plus /terms provide clearly labeled legal-review structures.

Information architecture

/
├── header and navigation
├── hero and primary CTA
├── problem and outcome
├── product workflow
├── feature groups
├── use cases
├── product proof/screenshots
├── availability
├── FAQ
└── final CTA

/app
/b/:slug
/privacy
/terms
/api/marketing/leads
/api/marketing/events

A compact site is fine. Every section should answer a distinct objection rather than repeat the hero in smaller type. SignalRoom keeps availability on the homepage rather than adding a separate pricing route because paid plans have not launched.

The primary build prompt

Use this as the baseline build brief. Replace the product facts and routes first; the seven passes that follow refine individual risk areas rather than replacing the prompt.

Build a production-minded SaaS marketing site for a customer-feedback product.

Product:
- Audience: small SaaS teams
- Problem: feedback is fragmented across email, chat, spreadsheets, and issue trackers
- Outcome: one public place to collect requests, let customers vote, and communicate roadmap status
- Primary CTA: Start a free workspace
- Secondary CTA: View a public demo board
- Do not invent testimonials, customer logos, security certifications, usage statistics, or guarantees

Stack:
- React 19 and Vite 7
- TypeScript strict mode
- Express 5 same-origin API
- server-side product-updates form handling
- email adapter boundary; claim delivery only after a real provider is approved and exercised
- first-party analytics with explicit conversion events
- Vitest for validation and event logic
- Playwright for browser tests
- Vercel deployment

Build:
1. Responsive header with logo, product links, availability, sign in, and primary CTA.
2. Hero with specific problem/outcome copy, primary CTA, secondary demo CTA, and an honest product visual placeholder.
3. Problem section describing fragmented feedback without fake statistics.
4. Three-step workflow: collect, prioritize, communicate.
5. Feature groups for public boards, voting, comments, moderation, roadmap status/history, organizations, and team roles. Keep notifications explicitly deferred.
6. Use cases for founders, product managers, and support teams.
7. Availability section whose free-preview status and CTA destinations come from one typed configuration object. Do not invent paid tiers or limits before billing exists.
8. FAQ covering current submissions, voting, moderation roles, availability, and visibly deferred private boards or notifications.
9. Final CTA.
10. Privacy, terms, and contact page structure with clear placeholders requiring legal review.
11. Working product-updates form with server validation, honeypot, rate limiting, duplicate handling, success/error states, persistence, and an email adapter boundary.
12. SEO metadata, canonical URLs, sitemap, robots, Open Graph image configuration, and appropriate structured data.
13. Analytics events for primary CTA, secondary CTA, pricing CTA, form start, form success, and form error. Do not capture form content or personal data in analytics.
14. Accessible landmarks, heading order, labels, visible focus, keyboard navigation, error announcements, reduced motion, and color contrast.
15. Performance budget for JavaScript, images, fonts, layout shift, and third-party scripts.
16. Loading, failure, spam-blocked, duplicate, and retry states for the form.

Engineering requirements:
- Create a typed site/product configuration for URLs, plan names, limits, and contact details.
- Keep API keys server-only.
- Validate and normalize all form input on the server.
- Do not expose email provider or analytics secrets to the browser.
- Prefer static rendering where personalization is unnecessary.
- Optimize images and reserve dimensions to prevent layout shift.
- Use system fonts or deliberately optimized local/web fonts.
- Avoid autoplay video and motion that ignores reduced-motion preferences.
- Add unit tests for form validation, duplicate handling, plan configuration, and analytics-event payloads.
- Add browser tests for navigation, CTA destinations, form success/failure, keyboard flow, mobile menu, metadata, and broken internal links.
- Provide .env.example with names only and deployment instructions.

Before writing code, return:
1. messaging brief
2. page outline
3. component map
4. form data flow
5. analytics event map
6. SEO plan
7. accessibility risks
8. performance budget
9. acceptance criteria

Stop for review before implementation.

Pass 1: Remove generic marketing language

AI-generated copy tends to substitute broad outcomes for product facts. Audit each section before those claims harden into the design.

Audit the messaging brief and page copy before implementation.

Remove or replace:
- revolutionize
- seamless
- supercharge
- next-generation
- unlock your potential
- all-in-one, unless every named capability is actually present
- unsupported “save hours” claims
- fake urgency
- invented testimonials, logos, customer counts, ratings, or security claims

For each section, identify:
1. visitor question
2. concrete answer
3. supporting product evidence
4. CTA, if needed

Keep one primary conversion goal and one secondary demo path.

A strong hero might say:

Collect product feedback without losing requests in email and chat.

That is less exciting than “Transform your product journey,” which is exactly why it works.

Pass 2: Build the form like a real endpoint

The moment the page accepts an email address, it needs backend behavior. Validation, storage, spam controls, and failure handling are no longer decorative details.

Implement the product-updates form end to end.

Requirements:
- server-side validation and normalization
- explicit maximum lengths
- honeypot field
- IP/user-agent-aware rate limiting without permanent raw fingerprint storage
- duplicate-submission behavior
- idempotent persistence where practical
- email-provider failure handling
- email adapter with no sensitive content; keep delivery unclaimed when no real provider is configured
- success, validation, duplicate, rate-limited, provider-failure, and retry states
- accessible error summary and field errors
- no personal form content in analytics or logs
- generic external error messages with useful internal diagnostics
- automated tests for validation, spam controls, duplicates, provider failure, and retry

Report actual test commands and results. Do not simulate successful delivery in the UI if the provider request failed.

Form questions to answer

• Where does the submission go?
• Can the same email submit twice?
• What happens when email delivery fails after storage succeeds?
• What does the user see when rate-limited?
• Are logs redacting the submitted message and email?
• Can bots bypass client-only validation?

Pass 3: Centralize availability and links

Availability copy drifts easily. A free-preview homepage should not advertise paid plans, billing, or limits that the application does not yet support.

Create one typed product configuration for:
- product name
- canonical origin
- app URL
- demo URL
- support/contact address
- availability label
- CTA destinations
- plan names, displayed prices, billing intervals, and plan limits only after billing exists

Render availability copy and repeated CTA links from this configuration. If paid plans exist, render pricing from the same source and test missing URLs, duplicate plan IDs, invalid limits, and inconsistent labels.

If the marketing site and SaaS billing system are separate, document how pricing changes are synchronized and reviewed.

Pick one source of truth for public pricing and document how changes reach the site. That does not require querying Stripe on every page request; a reviewed marketing configuration may be the safer choice.

Pass 4: SEO that matches the page

Implement and verify technical SEO for the marketing site.

Include:
- unique title and meta description
- canonical URL using the production origin
- Open Graph and social metadata
- robots rules appropriate to production and preview environments
- sitemap containing only canonical public pages
- favicon and web app metadata where relevant
- Organization and SoftwareApplication structured data only for facts the product can support
- descriptive image alt text
- one H1
- logical heading hierarchy
- crawlable navigation links
- useful 404 page

Prevent preview deployments from becoming canonical or indexable. Add automated checks for title, description, canonical, one H1, internal links, and structured-data parsing.

Structured data is not a place to invent ratings, prices, or availability. If facts are unavailable, omit the property.

Pass 5: Analytics without surveillance theater

Analytics should help answer a few concrete questions:

• Which CTA gets used?
• Do visitors reach the availability section?
• Does the form fail?
• Which page sends people into signup?

Implement an analytics event map with:
- primary_cta_clicked
- demo_clicked
- pricing_cta_clicked
- lead_form_started
- lead_form_succeeded
- lead_form_failed

For each event define:
- trigger
- allowed properties
- prohibited personal data
- duplicate prevention
- test method

Do not send email addresses, names, messages, tokens, full URLs containing private query values, or raw error stacks.

Respect the selected analytics provider's consent requirements. Do not add a decorative cookie banner disconnected from actual script behavior.

Pass 6: Accessibility and responsive behavior

Automated checks catch only part of the problem. This pass forces the agent to use the page at real viewport sizes and with a keyboard.

Audit the implemented site at 360px, 768px, and 1440px and with keyboard-only navigation.

Check:
- header/mobile menu semantics
- menu focus management, Escape behavior, and restoration
- skip link
- landmark and heading order
- descriptive CTA text
- visible focus
- form labels and error announcements
- availability-panel reading order
- FAQ disclosure semantics
- contrast
- zoom to 200 percent
- reduced motion
- touch-target size
- no page-level horizontal overflow
- long plan names and translated-length copy

Return a defect list with severity before fixing anything. Then fix and retest.

Pass 7: Performance budget

A landing page should not require a desktop GPU to display text and screenshots.

Suggested initial budgets:

• Minimal client JavaScript outside interactive controls
• No layout shift from images, fonts, banners, or late pricing content
• Optimized hero image with responsive sizes
• No unreviewed third-party scripts
• No autoplay background video by default
• No animation loop when the tab is hidden

Run a performance pass.

Inventory:
- client JavaScript
- third-party scripts
- fonts
- image formats and dimensions
- animation libraries
- hydration boundaries
- layout-shift sources

Remove code that does not support a user task. Record actual build output and measured results. Do not fabricate Lighthouse scores.

Testing plan

Unit/integration

• Form validation and normalization
• Honeypot and rate-limit decisions
• Duplicate behavior
• Provider failure and retry
• Availability configuration integrity
• Analytics payload allowlist
• Canonical URL construction

Browser

• Navigation and mobile menu
• Every CTA destination
• Form validation, success, duplicate, and failure
• Keyboard-only journey
• FAQ controls
• Metadata and one H1
• Internal broken-link scan
• 360px, 768px, and 1440px screenshots
• No horizontal page overflow
• Preview environment not indexable

Deployment and production smoke test

Use the vibe coding deployment checklist during the release and the AI-coded app launch audit for the final production pass.

Before deployment:

• Configure the production origin
• Add server-side email and persistence credentials
• Configure the sending domain
• Confirm preview robots behavior
• Generate and inspect the social image
• Run build and tests
• Check legal-page placeholders are clearly marked and not presented as reviewed legal advice

After deployment:

• View page source for title, description, canonical, and structured data
• Submit a real test lead to the production endpoint
• Verify storage; verify confirmation delivery only when a real provider is configured
• Trigger a controlled provider failure if the environment supports it
• Inspect analytics events without personal data
• Test mobile navigation and keyboard flow
• Check forms on slow and failed networks
• Crawl internal links
• Inspect console and network errors
• Confirm the app, demo, sign-in, and availability links are correct

Evidence required before publication

• Companion repository: Poseyv12/signalroom-feedback-saas, pinned at commit e65482e.
• Build result: Vite production build passed; client output was 1.67 kB HTML, 19.40 kB CSS (5.05 kB gzip), and 223.86 kB JavaScript (68.55 kB gzip).
• Automated test result: As verified on July 13, 2026, 54 Vitest tests passed across seven files; typecheck, lint, build, dependency audit, and diff check passed. GitHub Actions run 29294467495 passed on the final demo-roadmap commit.
• Form storage/delivery evidence: Validation, normalization, duplicate, honeypot, rate-limit, storage-before-adapter, provider-failure, success, and retry behavior passed. Real email delivery is not configured or claimed.
• Analytics event evidence: The first-party event/property allowlist passed API tests. Form start, success, and failure payloads passed browser tests; entered email and company values were absent from analytics payloads. CTA event names are server-allowlisted but are not claimed as wired in the current client.
• Metadata/canonical evidence: Canonical, Open Graph, robots, sitemap, one H1, and parseable truthful SoftwareApplication JSON-LD tests passed.
• Performance measurements: Production bundle sizes are recorded above. No Lighthouse score is claimed.
• Accessibility/browser findings: Six Playwright flows passed across Desktop Chrome and Pixel 7 with zero axe violations and no horizontal overflow after real contrast defects were fixed.
• Production URL: signalroom-feedback-saas.vercel.app. Homepage, app, legal routes, branded 404 shell, public AcmeFlow demo roadmap, health endpoint, lead storage, and analytics storage were verified over HTTPS. Persisted marketing smoke records remained after a fresh production redeployment.
• Known limitations: Distributed rate limiting, real email, retention policy, legal review, backup-restore rehearsal, Firefox/WebKit, practical screen-reader testing, and third-party penetration testing remain open.

Common failures

The CTA does not go anywhere

A button with no valid signup, demo, or waitlist path is decoration. Every CTA needs a reviewed destination and an error-resistant route.

The form lies about success

Do not show “You are on the list” before the server confirms its intended persistence behavior. Decide whether storage or email delivery defines success and handle partial failure honestly.

The site claims proof it does not have

Do not generate customer logos, testimonials, ratings, compliance badges, or usage counts. Placeholder content has a habit of reaching production.

Preview deployments become indexable

Preview URLs should not compete with the canonical production site. Verify robots and canonical behavior in both environments.

Analytics captures form data

Event names and allowed properties should be explicit. Never spread the full form object into an analytics call.

FAQ

Should the landing page live in the SaaS repository?

For a small team, usually yes. Keeping the landing page beside the application makes it easier to reuse types, URLs, availability rules, and deployment configuration. Split it out only when marketing genuinely needs a separate publishing workflow or release cycle.

Do I need a CMS?

Not for the first version. Add one when non-developers need to publish frequently. A CMS adds authentication, previews, content modeling, and another failure surface.

Can AI write the product copy?

It can produce useful drafts after you define the audience, problem, outcome, proof, and objections. Without that brief, it will produce confident filler.

Is a landing page production-ready without legal review?

The software can be technically ready, but privacy, terms, claims, and consent obligations may still require qualified review. Label placeholders and avoid claiming legal compliance.

What to do next

Build the landing page as part of the product, not as a detached marketing mockup. Its availability, links, forms, and claims should agree with the application behind it. Once deployed, test it as a first-time visitor: can you understand the product, try it, and recover when something fails?

Try the live SignalRoom landing page, then read the SaaS feedback-board build guide for the application behind it. For smaller interface experiments, use the copy-ready examples in the frontend prompt library and UI/UX prompt library.