#002
Bolt.new

Figma Make to Code in Minutes (Bolt.new Does It ALL)

Turn Figma Make landing-page designs into clean HTML/CSS (minimal JS) with Bolt.new. We'll stitch screenshots, use a prompt, debug, and polish responsive mobile UI

Figma Make → Code in Minutes (Bolt.new Does It ALL)

TL;DR

  • Split a Figma Make landing page into 4–5 stitched screenshots so Bolt.new can reconstruct the full page.
  • Use a tight prompt to force HTML + CSS + minimal vanilla JS (no React/TS/frameworks) with high visual fidelity.
  • Run an iteration loop: fix common “blank page” errors, then polish mobile spacing + styling issues with targeted feedback + screenshots.

What we’re building

A static landing page generated by Bolt.new from a Figma Make design, matching the screenshots closely and behaving well on desktop + mobile (sticky nav, responsive layout, light interactions).

Stack / tools

  • Figma Make (design generation)
  • Bolt.new (design → code)
  • HTML + CSS + vanilla JavaScript (minimal JS, static hosting-friendly)
  • Lucide icons (avoids emoji defaults; clean icon set)
  • Optional: Google Maps embed/key later for the “service area” map section

Pre-requisites (keys/accounts)

  • Bolt.new account (free tier works for this flow)
  • Figma Make access (to generate the design)
  • Optional (later / for the map section): Google Maps API key
  • Optional (next episode): Airtable or Google Sheets (for form submissions)

Steps

Step 1: Prep the Figma Make design for Bolt (screenshot stitching)

Bolt.new has an image limit (commonly 5 images), so the goal is to capture the entire landing page in 4–5 overlapping screenshots that the model can “stitch” together.

  • Aim for top-to-bottom coverage of the page
  • Include a small overlap between screenshots (e.g., a bit of the same gray background/footer area) to communicate continuity
  • Don’t reshoot the sticky navbar in every frame—call out “sticky navbar” in the prompt instead
  • Tip: zoom out (e.g., ~80% viewport) so each screenshot captures more content

Step 2: Write a strong “screenshots → static site” prompt

Your prompt should explicitly say:

  • The screenshots are one continuous page (ordered top → bottom), not separate pages
  • Output must be static:

    • index.html
    • styles.css
    • script.js only if needed (otherwise the model tends to overuse JS)
  • Require semantic HTML and high visual fidelity to the screenshots

  • Specify icon approach: Lucide (avoid emoji icons)

  • Define responsive requirements:

    • Desktop + mobile behavior
    • Sticky navbar
    • Mobile hamburger menu (explicitly call it out)
  • Call out section-specific layout details (e.g., “Trusted by homeowners” should be scrollable, not stacked)

  • Add interaction expectations (hover states, menu toggles, etc.)

Step 3: Upload screenshots + prompt into Bolt.new (free tier-friendly)

  • Upload screenshots in order (top → bottom)
  • Paste the prompt
  • If the prompt is too long, Bolt may store it as an attached file—this is fine
  • Add a short line of context like: “These are ordered screenshots + requirements—build the static landing page to spec.”

Step 4: Run the first build (expect a common “blank page” failure)

A frequent first-pass issue: Bolt returns a blank white page due to a small runtime error (often import/path-related).

Quick fix loop:

  • Reply with a short debugging prompt like: “It’s a blank white page—there’s an error. Please fix and rerun.”
  • Rebuild and re-check output

Step 5: QA desktop + mobile and note issues

Once it renders:

  • Check overall layout + fidelity
  • Verify sticky nav behavior
  • Confirm scrollable sections behave correctly
  • Test mobile view for spacing/cutoff issues
  • Identify any “active state” styling problems (e.g., unwanted red outline)

Example issues spotted in this run:

  • Mobile top bar area felt squished near the sticky navbar
  • A service card showed an unintended red outline (active/focus styling)

Step 6: Do a targeted refinement pass (with screenshots)

Bolt responds best to specific, section-based feedback.

Pattern to use:

  • Praise + confirm direction (“looks great”)
  • List two concrete issues
  • Reference sections by name (“Emergency Dispatch”, “Comprehensive Plumbing Services”)
  • Attach a mobile screenshot showing the issue
  • Tell it exactly what “fixed” means (e.g., “cleanly stack”, “no outline, match others”)

Result:

  • Mobile spacing cleaned up (better stacking)
  • Red outline removed and styling normalized
  • Minor enhancements may appear (like subtle dividers)—usually fine if consistent

Step 7: What’s next (next episode setup)

Next, you’ll connect the form inputs to a backend-lite destination:

  • Airtable or Google Sheets, then
  • Deploy the static site so it’s live and shareable as a link

Prompts

Bolt.new Starter Prompt

You will receive multiple screenshots of the same single-page landing page, ordered from top to bottom. They are NOT separate pages. Use the overlap to align sections into one continuous page.

- Build a static landing page using only HTML + CSS + minimal vanilla JS (no TypeScript, no React, no frameworks)
- Output files: index.html, styles.css, script.js (only if needed)

Visual fidelity
- Match screenshots closely: layout, spacing, typography, colors, section structure.
- Use semantic sections: header/nav, hero, features, testimonials, pricing (if present), FAQ, footer.
- Fully responsive for mobile, tablet (iPad), desktop.

Icons (important)
- Use Lucide icons via CDN only (vanilla JS). Include the Lucide script and render icons using lucide.createIcons() (or equivalent).
- Sticky navbar + responsive behavior (very important)
- The navbar must be sticky/fixed and usable on mobile with a hamburger menu.

Desktop / large screens

- Navbar shows: Brand/title (“OC EMERGENCY PLUMBING”), nav links, and a prominent red CTA button (e.g., “CALL 24/7”).
- Sticky behavior: stays visible while scrolling.
- On scroll: add subtle background + shadow/blur so it’s readable over content.
- Ensure sticky navbar doesn’t overlap page content (add appropriate top padding/margin to body/hero).

Mobile layout requirement (single row)

- On mobile viewports, the navbar MUST be one row with three items
- Red CTA button on the left
- "OC EMERGENCY PLUMBING" text in the middle (shrink font-size as needed to fit)
- Hamburger icon on the right
- No second row. No stacking.
- The middle title can truncate slightly or scale down, but must remain readable.

Mobile hamburger menu behavior

- Hamburger toggles a dropdown/slide-down menu that contains nav links.
- The opened menu must be styled cleanly: readable text, spacing, background, and close behavior.
- Clicking a nav link closes the menu and smoothly scrolls to its section.
- Prevent scroll-jank: body should not shift weirdly when the menu opens.

Section-specific responsive requirements (must implement)

1. "TRUSTED BY HOMEOWNERS ACROSS ORANGE COUNTY" section:
- The badges/logos (e.g., BBB, HomeAdvisor, etc.) must be in a horizontal row that is scrollable on mobile AND tablet (iPad).
- They should NOT stack on smaller viewports.

2. "DON’T LET A LEAK BECOME A FLOOD" section:
- On mobile, the two buttons should be side-by-side (not stacked) if space allows.
- If extremely narrow, allow wrapping gracefully, but prioritize side-by-side.

3. "SERVING ALL OF ORANGE COUNTY" cities list:
- On mobile, display cities as two columns (not one long single column).

Interactions
- Smooth scrolling for nav links (CSS scroll-behavior or small JS).
- Buttons can be placeholders (no backend), but must have proper hover/active styles.

Implementation notes
- Use sensible breakpoints for mobile responsiveness
- Keep code clean and simple. Prefer CSS solutions; use minimal JS only for hamburger toggle + optional scroll shadow class.
- Use placeholder images/icons where needed; keep styling consistent with the screenshots.